December 26th, 2009
Here's what I'm using to upgrade WordPress:
A WordPress installation can be divided into three parts. The first
part involves the core WordPress folders: wp-admin and
wp-includes. You normally don't change anything in these
folders, so upgrading them can just be a matter of deleting what
you've got and replacing it.
The second part involves customized folders. The most important of
these is wp-content, since it contains your site's theme
and plugins, but you might have other folders that are similarly
off-limits as far as upgrading is concerned. Whatever happens during
the upgrade process, we don't want to touch this stuff.
The final part involves the PHP files at the root level of the
site. These are mostly wp-* files that aren't changed,
except for wp-config.php, which is.
Conveniently, the URL for the latest version of WordPress is always
the same. I use curl to download it to /tmp
because it allows me to pipe the download straight into tar. After
deleting the core WordPress folders recursively, I rename
wp-config.php and any other custom PHP files (in this
example, share-via-email.php) with a .bak
extension so that they'll be preserved during the subsequent wipeout
of all PHP, HTML, and TXT files in the site root.
From this point, it's just a matter of copying in the new files and
restoring the .bak files to their original name. Since
the deletion process was restricted to known extensions, the only risk
is in forgetting to make an exception for customized files. Version
control can help with that, especially if you've accidentally
deleted or overwritten something important.
I haven't accounted for .svn folders within the core
folders. If you ran this target as-is, Subversion would complain about
the sudden absence of .svn folders within the
newly-copied wp-admin and wp-includes. This
is a great reason for exploring other options like git
that centralize all their stuff in a single directory.