Thoughts on my multi-developer WP setup with Roots

Hey all,

I first want to thank the Roots team for creating such an amazing WordPress tool. I’ve known about it for over a year, but it hasn’t been until recently that I revisited the project and seen how much it’s grown as well as how it coincides with an upcoming project I will be working on.

Although there are many different setups for a multi-developer situation, I’m examining the following approach.


(1) Each developer checks out and contributes to a central git repo

This setup is described in the roots documentation and screencasts. Meaning /app/ (aka wp-content which contains your custom plugins and custom roots theme), /composer.json, /composer.lock and /index.php are under source control; and with /wp-config.php and /.htaccess NOT in source control and independent for each developer (and ultimately the live site… explained further); /wp/ and /vendor/ come from composer update (as described in the roots documentation and screencasts)

(2) Each developer has their own local web server to run the above files

A developer on Windows may run WAMP, a developer on OSX may run MAMP, or maybe virtual machines are involved.

(3) Each developer runs off of the same master database.

Even though each developer has their set of the site files checked out from source, which are being used to run the site on their local machine, their wp-config should all point to the same MySQL database hosted on a server that allows outside connections. Note: this can sometimes be an issue. For example, let’s say developer1 creates a new template, then creates a page with that new template and saves it. Then developer2 edits that page, but hasn’t updated his repo and therefore doesn’t have the new template file, then WP may revert back to the default template. To circumvent this, some team communication may be required when templates and custom post types are made.

The benefit is that you’re working on the same content without having to sync anything.

(4) Each developer overrides the default WordPress Address and Site Address

Given that each developer has their own local web server, the URL which they use to access the site locally may differ from developer to developer. For example:

Since all the developers are running off the same database as described above, this doesn’t play well with WP’s “WordPress Address (URL)” and “Site Address (URL)” since WP doesn’t use relative URLs. If this issue isn’t addressed, then any generated hyperlinks (like those made by WordPress’s menu builder) will point to somewhere off of their local machine. Fortunately, there is a way to work around it.

Let’s say the database is set to the following URLs (which reflect the WordPress in a subdirectory setup described in the roots documentation and here: Giving WordPress Its Own Directory « WordPress Codex):

Then, developer1 would override it like so, by placing the following at the top of his wp-config.php:

define('WP_SITEURL', 'http://dev1.webhop.net:1234/something.com/wp'); // Overrides Admin - Settings - General - WordPress Address (URL)
define('WP_HOME', 'http://dev1.webhop.net:1234/something.com'); // Overrides Admin - Settings - General - Site Address (URL)

And developer2 would override it like:

define('WP_SITEURL', 'http://localhost/wp'); // Overrides Admin - Settings - General - WordPress Address (URL)
define('WP_HOME', 'http://localhost'); // Overrides Admin - Settings - General - Site Address (URL)

And developer3 would override it like:

define('WP_SITEURL', 'http://something.local/wp'); // Overrides Admin - Settings - General - WordPress Address (URL)
define('WP_HOME', 'http://something.local'); // Overrides Admin - Settings - General - Site Address (URL)

(5) Amazon S3 used to store all media uploads

This prevents the issue of (a) image synchronization and (b) URLs of image assets that point to a developers local URL structure. The following plugin worked perfectly for me: http://wordpress.org/plugins/amazon-s3-and-cloudfront/


I’d like your guy’s feedback. Perhaps I can make a screencast demonstrating the technique after some working out any issues that I may not have noticed.

Jonathan

1 Like

This is a good start. There’s a few things I’d personally improve upon:

  1. Great. Nothing else to do here.
  2. Yep each developer should have their own local dev environment but this should really be standardized since the goal is dev/prod parity. Virtual Machines really help here.
  3. It’s good to run off of the same database but in my opinion it shouldn’t be a central/remote that everyone uses. Each dev should have their own local DB with a copy of the latest DB. Yes this makes it harder to sync but it avoids troubles with lots of people changing the database concurrently.
  4. Ideally #2 takes care of this and it’s the same for everyone.
  5. Ditto. S3 is great.