• Robots.txt
  Robots.txt needs to be different in each level of DEV, QA and PROD.  If you are using SVN this can be a challenge.  If you don’t know what SVN or CVS are, then don’t worry about this one.  Basically as you copy the site from DEV to QA to PROD, you end up with the same robots.txt.  This can’t happen from a technical perspective, since you really want robots.txt to block the search engine bots on DEV and QA, and not on PROD.
• wp-config.php
  wp-config.php, the settings file for WordPress, needs to be modified if you are spanning the code across DEV, QA and PROD.  Simple answer for this, use the old PHP switch statement and change the site based on server name with case statements.  The variable to use for this is $_SERVER['SERVER_NAME'].    A good example is below:

  // ** MySQL settings – You can get this info from your web host ** //
  switch( $_SERVER['SERVER_NAME'] )
  {
  case “dev.strategicpoints.com”:
  define(’DB_NAME’, ‘dbname’);
  define(’DB_USER’, ‘dbuser’);
  define(’DB_PASSWORD’, ‘dbpassword’);
  define(’DB_HOST’, ‘localhost or SERVER NAME’);
  break;

  case “qa.strategicpoints.com”:
  define(’DB_NAME’, ‘dbname’);
  define(’DB_USER’, ‘dbuser’);
  define(’DB_PASSWORD’, ‘dbpassword’);
  define(’DB_HOST’, ‘localhost or SERVER NAME’);
  break;

  case “www.strategicpoints.com”:
  case “strategicpoints.com”:
  define(’DB_NAME’, ‘dbname’);
  define(’DB_USER’, ‘dbuser’);
  define(’DB_PASSWORD’, ‘dbpassword’);
  define(’DB_HOST’, ‘localhost or SERVER NAME’);
  break;
  }
  

• Server Name in Mysql
  It is important to make 2 changes in each DB when migrating MYSQL between DEV, QA and PROD.  These are in the wp_options table, and if you have been through this drill before they are pretty explanatory.  The option names you have to change are “siteurl” and “home” to the full path of the site such as http://www.strategicpoints.com.

To solve some of these incompatibilities between the DEV, QA and PROD there are plugins and other things that need to be put in place in order to keep these versions in sync.  This is a major challenge.  As I solve each one of these issue or more issues, I am going to update this blog post.

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