My Super Ex-WordPress
March 7th, 2007Anybody running WordPress should be aware of the recent security breach at WordPress HQ, that caused a pretty troubling “tainting” of the 2.1.1 release distribution. The funny thing here is, if you updated to 2.1.1 early enough, or if you got the sources directly from the Subversion repository, you’re “safe.” Well, relatively safe. They apparently added some more security fixes to 2.1.2, so it’s a good idea to upgrade anyway.
If you run WordPress, you’ve probably discovered that upgrading can be somewhat tedious – especially if you have custom changes. The problem is you need to apply all the modified files to your blog directory, without destroying anything custom you’ve popped in there yourself. Assuming you haven’t modified any core files the process is a simple matter of updating the core files while leaving your custom files, e.g. themes and plugins, alone.
For a long time I did these updates by unzipping the release files directly to the affected directory. It turns out that the unarchiving process was “non-destructive” in the sense that it wouldn’t overwrite an entire directory just to update one file. So that worked pretty well. But then one day lurking in the IRC #wordpress channel, I learned a great tip, which is to use Subversion directly to export the release onto your blog directory.
I use Subversion myself for all my web files, so it’s easy to “play with fire” and run a command like this:
svn export --force http://svn.automattic.com/wordpress/tags/2.1.2/ ./
What this does is spray all the files from a particular release (in this case 2.1.2) into my blog directory. Since I’m also running svn, I then have the luxury to “svn status,” “svn diff” etc, and compare the changes. I then test the upgrade and commit the changes to my personal svn repository when everything looks OK.
This technique has essentially cut my “time to upgrade” for WordPress down to about 2 minutes – and I don’t have to deal with downloads, packages, etc. The only downside I can imagine is that if WordPress removes a file, I’ll have a stale copy of it. I suppose I should look into an improved technique that would consider this – but it hasn’t been a problem yet.
March 7th, 2007 at 11:29 am
If WordPress removes a file, the file dissapears from your local copy. If the file is unchanged, it just goes away. If you did any modifications, there will be a file.php.mine or a file.php.rXXXX.
So, my steps are:
# update local copy with remove files
$ svn up
# check if there’s any conflict…
$ svn status | grep -E “^C ”
# …or just change for the >>>>
$ grep ‘
March 7th, 2007 at 11:44 am
Indeed, when worpress “rm”s a file in the repo it will also go away with an update at your local working copy UNLESS you have local changes. SVN reports this as a conflict and asks you to resolve it.
So your practice is a very nice way to update a wordpress blog. I’m going to look into it as well. Thanks for the tip. :)
March 7th, 2007 at 12:56 pm
I believe svn would highlight any difference between your local copy and the remote repository, so you would be aware of removed files when trying to resolve conflicts.
March 7th, 2007 at 12:57 pm
Sorry for the duplicate comment above. I should have reloaded the page before posting. And maybe I should not post this excuse? Oh well…
March 7th, 2007 at 1:17 pm
Is it my imagination or are most of these comments not noticing that the article did an svn export, not an svn co. if He does an svn update, diff, whatever, it would be working against his local repository of modifications, not against the wordpress repository.
Then again, maybe I’m very wrong.
March 7th, 2007 at 1:22 pm
That’s why my comment was related to “my steps”, where I work directly against the WordPress SVN. This allows me to backup my site via storing the svn diffs, and to generate patches to send upstream, when needed.
Or in other words, the changes relative to my personal site should be fully contained inside the wp-content/plugins. If the svn diff command doesn’t return empty, then something wrong is happening on the wordpress codebase – either a bug, or a missing hook in the code.
March 7th, 2007 at 2:30 pm
Yeah he is running an export. Oops :) (I missed the export too)
But then again, do a fresh export, compare that with current running version and the untouched previous version: you’re good to go.
March 7th, 2007 at 2:34 pm
I use Blogspot. It might not have all the bells and whistles, but I don’t have to worry about installation, migration, security, etc. A few minutes here and a few minutes there, and we’re talking real time!