This article is the 4th of a series of articles about WordPress In The Enterprise. This article is a work in progress, I am going to add to it as I go about this process, since I am tackling an issue that right now has no easy answer in the enterprise, and that is how to upgrade enterprise driven WordPress implementations. Why upgrade? Well, every chicken little on the WordPress blog/web has said if you don’t you may have a security issue. This is the kind of corporate implementation that includes a development server, a QA server and a load balanced production server.
If you want to start at the beginning and read them in a sequence use the following links below:
WordPress For The Enterprise – Article 1 – Setting The Mood
WordPress For The Enterprise – Article 2 – Issues And Plugins
WordPress For The Enterprise – Article 3 – Implementation Problems
Ok, now that you have read up on the first series of articles, let’s get to the heart of the problem with upgrading from an enterprise perspective. First off, the real issue is that WordPress is not an enterprise product, just yet. This does not mean it won’t be in the future, so like a WordPress plugin that does not yet exist, we have an issue that just needs to be solved. The big issue is testing a new WordPress Version on a development server and then somehow easily upgrading the QA and production servers.
Upgrade Method
If you use the WordPress upgrade method right out of the box, you are somehow violating a holy grail of upgrading from development to QA to production. Or are you? The current WordPress recommended method of upgrading is to load the new set of version files like from 2.8 to 2.84 (not overwriting wp-content’s themes & plugins directories, or anything else unique) and just letting the new version, like 2.8.4 do its magic. By magic, I mean it sometimes, but not always makes modifications to MySQL table structures. If that were not an issue, this would kind of be a mute point, because then we would just copy the development site over and be done with it. If you need the most recent version of WordPress, you can get it by clicking here.
Testing Plugins
Let’s take a little diversion here. Obviously one of the most important issue in the enterprise solution that I am trying to figure out, is testing plugins. Apparently you have to update certain plugins with the most recent version of the plugin to make sure it is compatible with an upgrade. This is a bit taxing on plugin makers who have to keep up with major revisions. The task at hand is to test plugins like seo-all-in-one-pack, google analytics, redirection, and others for compatibilities. If a very important plugin can not be upgraded and remains incompatible with the new Version, well, let’s just say you will be going to the backup.
The Backup
An important step in the upgrade process is the backup. I am not talking about the system backup you get from your server folks when the server crashes dead as a doornail, I am talking about backing up MySQL fully before you do the upgrade. Not explicitly required for the non-enterprise version, but for enterprise it is a must. Simply back it up to a .sql file and keep it handy, even in the development site before an upgrade. Good practice and that is what enterprise WordPress is all about.
The Upgrade Process
Once you have gone through the standard copy of the files over the development, you need to surf wp-admin area of WordPress. Immediately it will come up and there is a button that says UPGRADE to version x.x.x. You click it and hopefully it all goes well. Simple enough and that dev version is upgraded.
The QA Process
Tedious as it is, you need to go through and not just test out the content, permalinks and categories, but you need to take a look carefully at the plugins from both a site perspective on the outside and in the admin and tools areas as well to make sure they are functional on the inside. Once this is complete and tested, it is time to push it.
Pushing It
By pushing it, I mean pushing files up to the QA server, along with a mysql copy. This may be more of an SA task, but up till now it has been in the hands of the person managing the WordPress version. If you had left it purely up to SAs, it probably would not have happened right. All that has to happen at this point in the process is complete duplication of 2 things: files and Mysql DB. The duplication on the QA and production server will complete the process…hopefully.
Until somebody writes the ultimate publishing plugin for WordPress Enterprise, this will be a bit of black hole. Trust me somebody out there is going to fill this void. We have been hard at work on our own internal WordPress publishing plugin, but I am sure there will be open source versions sometime soon on the web.
Dan
Next Article WordPress In The Enterprise – Article 5 – Post Mortem