Posts tagged with " shell access"

Blog Upgrade: WordPress 2.8.3 FAIL

Sunday, 09/08/2009 ≅13:03 ©brainycat

The wordpress team finally got the bugs worked out of the new release. So began the process of upgrading. I run all my sites off of svn, which makes life easier in several ways: I have backups, I can rollback changes, and I can hack at the software and keep my changes even as the vendors release new updates.

Of course, keeping my own changes means merging. I learned a lot about how svn works when I was trying to merge 2.8.3 into 2.7.1. First of all, when the docs indicate you should keep a /current directory with the vendor changes, they aren't kidding! I tried to skip /current, and just merge the 2.8.3 tarball into /trunk (where the live site lives). No dice. Svn indicated that nearly every file changed, some files got dropped, some files didn't get updated, and all manner of wonkeyness ensued.

Here's how I (recall I) got it to work:

  1. Backup your repo:
    svnadmin hotcopy /path/to/repo /path/to/backup
  2. /branches/wordpress/VERSION

    is the original tarball. Import the whole tarball, then delete the themes and commit again.

  3. /branches/wordpress/current

    is where svn "holds" or "tracks" the diffs between the versions. You will need to know the last REV you committed in VERSION-OLD (VOREV) and VERSION-NEW (VNREV), as well as the REV of your last commit in /trunk (TREV). After you've got two tarballs checked in, issue:

    $ svn merge /branches/wordpress/VERSION-OLD@(VOREV) \
    /branches/wordpress/VERSION-NEW@(VNREV) \
    /branches/wordpress/current
  4. Resolve conflicts.
  5. $ cd /branches/wordpress/current
    $ for x in $(svn status | grep \? | cut -c 8-); do svn add $x; done
    $ svn commit

    You will need to remember this revision number, we'll call it DIFFREV

  6. $ cd /trunk
    $ svn merge /branches/wordpress/current@DIFFREV ./@TREV
  7. Resolve conflicts.
  8. $ for x in $(svn status | grep \? | cut -c 8-); do svn add $x; done
    $ svn commit 

In the course of discovering this procedure, I blew my repo to pieces. Fortunately, I had made a copy. I logged into my server, cd /svn/REPONAME; rm -rf ./* and cp -r /path/to/backup/* . Unfortunately, my shell user doesn't have the same permissions as the svn user. I got all kinds of "unable to write journal" errors when I tried to commit from my working copy. I filed a ticket with my host, and they rectified the permissions in a few minutes.

<Unsolicited gushing about my hosting provider>
As an aside, I looked around at svn specific hosting, looking for a host that provided lots of space, not a lot of users, and had an environment where I wouldn't have to file a ticket everytime I restored a backup. I found that Dreamhost is clearly the most cost effective svn host. I couldn't find another hosting service that provides unlimited access to hooks. Most of the hosts are charging exorbitant amounts of money for more than 100MB of space, and at that level you're limited to one repo. By the time I could get into unlimited repos and at least a GB of disk space, I'd be spending nearly as much as I'm paying for my complete hosting package with two virtual private servers and unlimited disk and bandwidth.
</Unsolicited gushing about my hosting provider>

I also upgraded my plugins, but as I'm not hacking on any of those on this site, it was a simple matter of copying the tarball into /plugins/PLUGINNAME, adding new files with for x in $(svn status | grep \? | cut -c 8-); do svn add $x; done and then committing the changes.

All in all, I don't really notice a lot of difference with 2.8.3. I notice the updates to the plugins more, namely Twitter-Tools and All In One SEO pack. I still LOATHE the administrative interface; all that AJAX is glacially slow on Firefox in Linux. But, as I'm sure it's zippy in Safari, we can't expect it to change anytime soon. In a perfect world, you could build your admin interface with admin-template tags just like you do the front side. I was worried about the changes to the database, but since I use get_*() to call the DB, the changes are transparent to me. I am excited about learning more about page classes; if they do what I think they do, I can put them to good use shortly.

But then 14 hours later, when I was checking my site from my wife's pc, I noticed there are some bugs that popped up. My hack to list my archives quarterly doesn't work - something, somewhere appears to be returning NULL results. Also, the pagination is wonkeyed. Fortunately, rolling back to 2.7.1 is as easy as redefining DOCROOT and hotrestarting the server. Total rollback time: 45 seconds. Closer examination reveals my quarterly archives are still wonkeyed, probably due to the database updates. This is what I get for failing to test my development environment thoroughly.

At least I know enough never to trust a .0 release and never rely on automated installs. I feel sorry for the poor schleps who are using wordpress but don't have the background in development or system administration, and rely on the pretty buttons to run their site. From what I've seen on the net, a way to large number of those sites got hosed.