Upgrading my desktop is a simple matter of clicking confirm. I know it is probably possible to set up WordPress to do the same, but I like to give the least amount of rights to the web-data user over my files. Here is my quick checklist of the 3.2.x upgrade to 3.3(.1)
Database backup
Don’t skimp on this step – if for some reason the upgrade fails you have the ability to restore it to it’s preupdate state. I create a full backup of the database:
mysqldump --user=root --add-drop-database --add-drop-table --complete-insert --routines -p WORDPRESS_DB > mysqldump_WP_TODAYSDATE.sql |
mysqldump --user=root --add-drop-database --add-drop-table --complete-insert --routines -p WORDPRESS_DB > mysqldump_WP_TODAYSDATE.sql
Note that I like using complete inserts and drop tables for ease of reading (and to closely follow more standard SQL).
New code shuffle
Download the new version of WordPress and expand the files. I don’t backup the uploaded wp-content
– I simply move them from the old locations to the appropriate directories in the new codebase. This way a backup of the old code also exists. Also worth noting that before moving the directories and files you need it’s probably a good idea to set the WordPress site under maintenance.
Here is the list of items you will simply need to move over:
/wp-content/uploads
/wp-config.php
– you can copy rather than move to save a backup
The other directories – /wp-content/plugins
and /wp-content/themes
– are a little more tedious: you compare the directory contents before you move things. However, if certain items have an update that coincides with the new WordPress then these can be upgraded directly into the new codebase.
Beware – if you have installed plugins that create their own directories outside the normal wp-content
convention you will need to move these too!
Permissions
You should have all the external assets (from WordPress) in the appropriate directories of the new codebase. Now check if the permissions need to be changed – like setting the group user to the web-data user or allowing code to be executable.
After this step, it’s time for the ‘great move’.
Move and test
Move or rename the old codebase, followed by moving or renaming the new codebase to the original location. Disable the maintenance and test out your new install. If you were logged in as an administrator before the change you should be able to see if you need to confirm any database updates from the dashboard.
Hopefully all the files and plugins are still in order and your site should look…. exactly the same as it did before.