The subject of WordPress workflows has been rife on Twitter today, and as a hardened WP developer, I thought I should chime in and share my optimal workflow.
In this little writeup I’ll show you how to:
- Handle multiple URLS
- Support for dev, staging & live databases
- Source control
- Deploying scripts
Before I get started, I just want to say that I’ll gloss over anything that isn’t WordPress specific. No particulars in version control or deployment scripts, just the bits that make it possible in WordPress.
I’ll assume this follows the 3 tiered development platform, meaning a local version for development, a staging server for showing the work to the client and the live version which the world sees.
So, when I start a project, the first things I do are set up a new source control repo and choose a local domain inside MAMP Pro. We’ll give this site a local domain of
mysite.dev, though that’s not important.
The next step is to download WordPress and chuck it in the appropriate place. The next step is a huge time saver. It means your install will work with any domain, no matter where it is, be it local, staging or live. This goes in
wp-config.php just before the comment that says
/* That's all, stop editing! Happy blogging. */.
// Assuming WP is in the root folder, adjust if not define('WP_SITEURL', 'http://' . $_SERVER['HTTP_HOST']); define('WP_HOME', 'http://' . $_SERVER['HTTP_HOST']); define('WP_CONTENT_DIR', $_SERVER['DOCUMENT_ROOT'] . '/wp-content');
WordPress is just PHP framework. There’s nothing you cannot do in it that you can do outside of it. So, using regular PHP
if/else statements, we can make WP work with different databases, depending on the URL.
wp-config.php, find the DB definitions.
// ** MySQL settings - You can get this info from your web host ** // /** The name of the database for WordPress */ define('DB_NAME', 'wordpress.dev'); /** MySQL database username */ define('DB_USER', 'root'); /** MySQL database password */ define('DB_PASSWORD', 'root'); /** MySQL hostname */ define('DB_HOST', 'localhost');
Replace the whole lot with the code below. I’ll comment it properly so you know what it’s doing.
$domain = $_SERVER[HTTP_HOST]; if ($domain === '') : // If is live enviroment define('DB_NAME', 'our_live_db'); define('DB_USER', 'our_live_user'); define('DB_PASSWORD', 'our_live_password'); define('DB_HOST', 'localhost'); elseif () : // If is staging enviroment define('DB_NAME', 'our_staging_db'); define('DB_USER', 'our_staging_user'); define('DB_PASSWORD', 'our_staging_password'); define('DB_HOST', 'localhost'); elseif () : // If is first developers local enviroment define('DB_NAME', 'first_env_db'); define('DB_USER', 'first_env_user'); define('DB_PASSWORD', 'first__env_password'); define('DB_HOST', 'localhost'); elseif () : // If is second developers local enviroment define('DB_NAME', 'second_env_db'); define('DB_USER', 'second_env_user'); define('DB_PASSWORD', 'second__env_password'); define('DB_HOST', 'localhost'); else () : // If none, fallback to these define('DB_NAME', 'fallback_db'); define('DB_USER', 'fallback_user'); // Usually 'root' define('DB_PASSWORD', 'fallback_password'); // Usually 'root' too define('DB_HOST', 'localhost'); endif;
if/else statements, you could make the database side of things work any way you want. You could just have the live environment then have everyone else (meaning every developer and staging environment) linked up to the staging database. That little snippet I mentioned earlier means domain & database issues just don’t exist, so long as you never hard-code a URL in, which is bad practice anyway.
I check in code as much as I can, I recommend you to too. Make sure the
wp-config.php is in source control too, or at least make sure it’s the same file across every developers system, as well as live & staging environments.
I currently use Beanstalk to host my SCM repos. They have a nice feature that deploys sites via (S)/FTP, be it the staging or live environment. They can even handle multiple servers, so if you have a load-balanced setup with multiple servers (without a replication script), you can deploy the code to each of those servers.
Hopefully these small tips mean you can work with WP across multiple environments with multiple developers. I’ve used this system on a site with 12 developers before, so I know it works.
Let me know if you have any tips, additions or changes.
Update [03/09/12 @ 12:25pm]
I’m digging up a few solutions and fixes to help with absolute asset URLs. I’ll post them here when I’m done.