tadhg.com
tadhg.com
 

My WordPress Development Setup

16:29 Fri 13 Feb 2009
[, , , , ]

One of the first things I did with my resuscitated blog was to figure out how I could develop for it in a reasonable fashion.

I’m pretty happy with the development environment at this point, the key features of which are:

Version Control: Subversion

Version control of some kind is simply necessary. If you really have to, you can do without something like Subversion, but there’s no real reason to—even if your host doesn’t give you shell access (in which case you should probably switch hosts), you can still use Subversion on your local machine, with your repository also running locally. That’s not an ideal situation, but it’s a lot better than no version control.

I strongly advise using the WordPress Subversion installation procedure, but with one alteration. You’re going to be keeping track of your changes in Subversion, and it’s not worth it to try to deal with svn externals for this. So instead of using svn checkout, use svn export, e.g.

svn export http://svn.automattic.com/wordpress/tags/2.7.1 .

(This also means that you should use svn export instead of svn sw when you’re upgrading.)

Separate Production and Development Code Trees

For small projects like this, a full suite of development, staging, and production isn’t necessary. But having both a production environment and a development environment is. These could be on separate machines, but in my case they’re on the same machine, as separate virtual hosts. Both code trees are local checkouts of the same project in Subversion. One useful trick for me was enabling error reporting on the development server:

php_value display_errors "1"

That line can be placed in either a .htaccess file or the VirtualHost section for the host. Here’s the list of php.ini directives, which tell you where they can be set/overridden.

Separate Production and Development Databases

You need to screw around with the WordPress database in various ways during development, and you don’t want that to alter your production site. Three simple steps will take care of this:

  • Create a new database (named something like yourwpdatabasename_development).
  • Back up the production database:

    mysqldump -u MySQLusername -p yourwpdatabasename > database_backup.sql
    

  • Alter the backup file to change the hostname from your production hostname to your development hostname. The easiest way to automate this is probably to create a file called dev_setup.sql with these lines:

    UPDATE wp_options 
    SET option_value="http://development_wp_url"
    WHERE option_value = "http://production_wp_url";
    

    and then use cat to append this to the backup file:

    cat database_backup.sql dev_setup.sql > development_load.sql
    

  • Load the altered backup file into the development database:

    mysql -u MySQLusername -p yourwp_development_databasename < development_load.sql
    

  • Change the wp-config.php MySQL settings in the development tree:

    /** The name of the database for WordPress */
    define('DB_NAME', 'yourwp_development_databasename');
    
    /** MySQL database username */
    define('DB_USER', 'yourwp_development_username');
    
    /** MySQL database password */
    define('DB_PASSWORD', 'yourwp_development_password');
    

    (The last two settings might not need to be changed.)

    One note here is that you should make sure not to check the wp-config.php file in to or out of your development tree.

  • Focus on Theme and Plugin Files

    It should be possible to make more or less all the changes you want without altering anything but plugin and theme files. If you do change the core WordPress files, you'll have to be more careful with tracking updates, so unless your changes are extremely minor or you're planning on forking WordPress, stick to the plugin and theme directories. Further, new functionality should really go in plugins if possible. It requires some more work to develop, but it's far easier to maintain, and will make dealing with future moves or upgrades significantly easier.

    So far, I've moved a 2.0 WordPress install over to 2.7, written a finished plugin and and unfinished plugin, installed several plugins, altered my theme, and installed an update (2.7 -> 2.7.1) using this environment, and it's all been quite smooth.

    One Response to “My WordPress Development Setup”

    1. Anne Says:

      So, would wordpress work for even noobs like me?
      Also, how are you these days?

    Leave a Reply