Enterprise WordPress – Things You Have to Change – Robots.txt, wp-config.php, etc.

After all the hullabaloo in getting WordPress ready and implemented for the enterprise, with a DEV, QA and PROD environment, there are a lot of small gotchas that are still sitting around. For those of you trying out WordPress for the Enterprise level, these are the little gotcha’s to worry about, and Robots.txt is one of them:

  • 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’);

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

    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’);

  • 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.

Load Balancing WordPress In Multiple Data Centers

When you work for an enterprise level company, things need to be accomplished at an enterprise level. So, that is why we have taken a variety of wordpress implementations, from basic to complex plugins and begun load balancing WordPress. To make things more complicated, the servers involved are not going to be in the same location.

Load Balancing, Why Do It?

  • Redundancy
    If one of your servers crashes, hangs ups or experiences a hiccup, you have another hot one ready to serve pages.
  • Server Speed
    If you are overloading one server, obviously a second server will resolve some of the speed issues if you are having IO issues. This is only if you are TechCrunch or Huffington Post.
  • HTML Loading Issues
    If you are far away from the server, yes it could take a long time to view a page. Ever wonder how long it takes to reach your website from Buenos Aires. If you wanted to know, look at a service like Gomez or Keynote. Not sure of any free services out there to tell you this, and if you find one definitely let me know the URL!

WordPress On Multiple Servers

I am sure Automattic has been doing this for the larger clients at a fee, and that is where some of their revenue is coming from, because this is where the pain kicks in, while implementing WordPress. If you have two servers that need to split the WordPress traffic load, this will work fine, as long as you can call them both the same name, with separate IP addresses. This is where the loadbalancer does its job. Not an expert at loadbalancing, but I have heard of an F4. Basically, it splits the load and sends web traffic either round robin or on some algorithm to each site. It can be tweaked if one box is acting up or doing something wrong. If there is extremely high volume of traffic, you could go to many boxes, but then you may want to look at cloud computing.

Load Balancing Across Multiple Locations

Now this is where the bigger issues come into play. For instance, if you were to creating multiple load balanced servers in different data center, including different international locations, you will have to deal with the issue of syncing of files and of syncing of either DB latency issues or distributed DBs.

The MySQL Database Issues

Sudden MySQL and pretty much every DB becomes an issue when you are running a site in mutiple locations. You can do it, and we are going to be running WordPress in a multi server environment soon, so we can experience the latency first hand. By latency, we are referring to a site in one city, let’s say Houston, and the DB in Los Angeles. That would mean every DB query would have to cross the country and there would be some delay in the query result arriving. This would also mean that there is a chance the site will be worse off than before the new remote servers go online, and what would be the point of that.

Solutions For The WordPress MySQL DB Issue

First solution to consider is Caching of content. Looking at wp-cache 2, and Super Cache, it is possible to have the individual sites create their own cache locally after one DB hit, or the first one after the cache times out locally. This would only make sense if you have a website with little dynamic content. This is good for web pages, but for rapidly changing blog comments or forums, it does not work, because it would mean it never will update proper. However, experimenting with this is a good thing, and will help.

The second solution is to come up with a way for the MySQL DBs to be sync’d on a regular basis, preferably offline. Possibly one way would be every hour or 5 minutes a script would kick off and check for any changes. The changes would be sync’d to the other DBs in the distributed network and you would be able to keep all the sites local MySQL and speedy. Good luck on this one. Maybe a plugin to do this, is the answer.