WordPress Workflow: 2 Sites, 1 Database

December 11th, 2012

If you’re like me, or thousands of other people, you like to develop WordPress sites via localhost solutions. But when it comes to moving your site online to show clients or the boss, you just know there is going to be a long back-and-forth process of changes, improvements and tweaks to the site. Having a “synced” local and remote copy is fairly difficult to manage for most. There’s a couple lesser known WordPress variables to help us all along to make it so we only need to have one database for both copies of the site. Of course, this means making sure when you first create your database, you create a remote one that your localhost copy can/will connect to.

Once you are ready to create a “live” development copy of the site, copy all your files up and open up wp-config.php on the remote copy. Before the line “/* That’s all, stop editing! Happy blogging. */”, place the following lines:

define('WP_HOME','http://www.example.com/path/wp');
define('WP_SITEURL','http://www.example.com/path/wp');

Change these to whatever your WordPress path to the site is. This will even work with subdomains or just straight up domains with no subdirectories. Just make sure not to include a trailing slash at the end. If your site is set up in some subdirectories (example: “/path/wp”) AND you are using SEO-friendly URLS (example: “http://www.example.com/nice-article-name”), then we will also need to edit the .htaccess file like so (using /path/wp as an example):

<IfModule mod_rewrite.c>
  RewriteEngine On
  RewriteBase /path/wp/
  RewriteRule ^index\.php$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /path/wp/index.php [L]
</IfModule>

And voila, both sites can connect to the database no problem. You, and most importantly, other users can add new posts, new plugins, new assets from either end. The only issue is merging the two and keeping them up to date. Which is why, once I set up this second remote copy, I usually always like to do everything on that version in terms of new assets/plugins, then just copy them back to localhost; however, when it comes to testing new theme functions, files, styles, JavaScript and that sort of thing, I can test them localhost first, then merge them to the remote copy so people who are potentially adding new content/plugins to the remote copy aren’t getting a broken in-development testing from your changes.

I’d eventually like to make this even more automated. If anybody has any ideas, I’d love to hear them.