Clearance - the workings of one David Paul Ellenwood

Little insights into my life.
Get cork'd with me!
Subscribe to the RSS 2.0 feed
Powered by WordPress
Get Firefox
© Copyright 1999-2019
David Paul Ellenwood
All Rights Reserved

WordPress Development Using A Shared Database

26 January 2011 0:04:03

Over at Sleeping Giant Studios, we have a number of developers all working on the same WordPress (WP) projects and using SVN (via Beanstalk) for source control.  As such, each developer’s workstation has a checked-out copy of the project codebase.  (And WordPress itself is in a subdirectory of the project as an SVN:External, but that’s another post for another time.)

We’re also using a shared development database meaning that everyone develops against the same database (and data) while maintaining separate working copies of the project codebase.  (We do this to reduce the amount of system administration we have to do on each workstation and also to ease content-entry sharing.) Working this way presents some problems because WP is designed to run against a single URL which gets stored in the database as a few different wp_options.

The workaround for this is actually pretty simple.  We define all of the URL options that WordPress needs as PHP constants in wp-config.php skipping whatever is stored in the DB.  Using the examples on the wp-config.php Codex page, we can even set these constants dynamically using PHP $_SERVER[] globals so we never have to hard code them to a specific URL.  For a default installation of WP in the root folder of a site we define a set of PHP constants in wp-config.php like so:

/** Sanitize SERVER_NAME, just in case **/
$server_name = htmlentities( $_SERVER['SERVER_NAME'] );

/** Custom WordPress core location **/
define('WP_SITEURL', 'http://' . $server_name);

/** Custom home location **/
define('WP_HOME', 'http://' . $server_name);

/** Custom wp-content location settings **/
define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/wp-content');
define('WP_CONTENT_URL', 'http://' . $server_name . '/wp-content');
define('WP_PLUGIN_DIR', $_SERVER['DOCUMENT_ROOT'] . '/wp-content/plugins');
define('WP_PLUGIN_URL', 'http://' . $server_name . '/wp-content/plugins');
define('PLUGINDIR', $_SERVER['DOCUMENT_ROOT'] . '/wp-content/plugins');

This allows each developer’s working copy to run using their workstation’s URL regardless of the values set in the database.

As with everything in life, there are a few issues with running this way.  Here’s a few we’ve noticed:

  • A rare plugin might not work this way.  Frankly, incompatible plugins are few & far between and we choose to avoid them because not using WP’s plugin best practices is foolish.
  • Posts (or pages or anything in the wp_posts table) added by each developer end up with GUID’s set to their workstation’s URL in the wp_posts table.  There are a couple other places this might creep up (in wp_options and some plugins’ custom tables for example).  This hasn’t caused any problems for us.  We tend to do a full search and replace for URL’s in the DB before going to staging or live deployments anyway.  This just means running the search and replace script against several URLs instead of just one.  We use’s SearchReplaceDB.php script to accomplish this.  It finds and replaces serialized and non-serialized strings throughout the entire DB.

In the future, I’ll planning to write up how we setup each project as an SVN repository using SVN:Externals to manage the WordPress core codebase and all the WordPress hosted plugins.

9 Responses to “WordPress Development Using A Shared Database”

  1. Realty South Says:

    Good day, I just hopped over to your website by way of StumbleUpon. Not something I might most often learn, but I liked your feelings none the less. Thanks for making one thing value reading.

  2. Raydel Says:

    Thanks for this post, is really useful, but you can tell me if the developers copy still going to server to take the css and jscript files?…

  3. DaveE Says:

    @Raydel I’m not sure I understand your question. Are you asking if the developers will share the same versions of the CSS & JavaScript files? If that is the case, the CSS & JS files will be managed by the Subversion repository, along with the rest of the source code.

  4. aaron Says:

    Have you guys been using this method with more recent versions of WP? I tried to follow your methodology, but keep pulling up a blank screen. Really hoping I can pull this off!

  5. DaveE Says:

    Hi Aaron, I do indeed still use this method with recent versions of WordPress. I’ve got a couple sites running this way right now. I’m not sure why you’re pulling up a blank screen. Without a bit more detail on the error it will be hard to diagnose.

    Can you make sure PHP errors are being printed, and that debug is enabled for WP? Also take a look att your server logs to see if anything’s showing up in there.

    I’ll drop you an email as well. Maybe we can continue diagnosing together.

    Good luck!

  6. Steven Chang Says:

    Currently changing my theme and have installed a copy of WP in a test directory – used your method above but the theme (most likely the stylesheets) doesn’t come through. Any idea?


  7. DaveE Says:

    Hi Steven, Off the top of my head if you’ve installed WP into a test directory, then you’d need to make sure the hard links used in wp-config.php properly reflect that. For example, if you’re subdirectory install looks like this: then the linsk in wo-config.php would need ‘/wordpress-test/’ added to them. Hope that helps,

  8. Matt Says:

    Hi Dave, thank a lot for that article. I’ve followed the instructions as far as I can tell and I’m getting a message saying “Database Update Required.” If I press the “Update WordPress Database” button my second site starts working but the first one starts getting that same message, and around we go. I’d appreciate any help here.


  9. DaveE Says:

    Hi Matt,

    I’m not sure what the issue might be there. Since there is only one database, the DB should be upgraded the first time you perform the upgrade. Have you checked the DB version in your database against what it should be to see if they match?

    If they do, I suspect it might be a cookie or session issue. I’d try clearing each browser’s cache before viewing it again.

    Sorry I don’t have a quicker fix.

New Extension