I'm trying to come up with a workflow for two (right now) people. One of whom will be doing theme work and another who will be writing content. We are not co-located are will not be anytime soon.

The writer is quite unfamiliar with source control, so that would best be a phase two kind of thing. I could put MAMP on her box and have her write there, if that is the approach, how best to integrate the two solutions?

I've read this question: How to best setup for development for a two person bi-coastal team? but since it is two years old, I thought I would see if anything has changed.

1 Answer 1


Caution: very mac/linux/unix centric thoughts ahead. Includes a lot of command line fu.

Put All the Code Under Version Control

I like git. Mark Jaquith has some good suggestions on keeping an entire site under version control using git and submodules for the WordPress core. You could also put plugins in as git submodules.

The developer end of the team will work locally, test and commit any changes, then push the code to a central repository (Github with a private repo, Beanstalk, Your server, it doesn't matter). From there you can use deployment tools (Capistrano, etc) or simply SSH into your development server (see step 2) and git pull in your changes.

Be sure to add your static file directories (eg. uploaded images and content) to your .gitignore file.

Set up a Development Server

Eg. install WordPress on a subdomain of your main site, like staging.yoursite.com or dev.yoursite.com. This is testing ground for new code and where your content producer will work. I'd recommend keeping this on a separate sever entirely.

Give your content product a username and password to the staging site, and have them produce and write all the content there. You'll also pull in the latest code changes to this site to test here before pushing them to the production (live) site.

From the development server you can do a hard database export and use that to put all the content on the live site.

On the dev server:

shell$ mysqldump -p -u your_dbuser yourdatabase > the-file.sql

Send the file over the production server and...

shell$ mysql -p -u your_dbuser your_database < the-file.sql

There is another alternative that I've just recently had the pleasure of working with called RAMP by Crowd Favorite. It will deploy content from one server to another for you. It is awesome. Highly recommended.

When everything is ready to go, push content and code to the live site.

As a final word of caution: IP restrict your dev site so not everyone can access it.

Syncing Your Local Development Site

Obviously if you're goign to work locally, you want to keep your local site in sync with the development and production sites. All your code will be under version control, so that's no problem. But syncing the database and static files is another matter.

Syncing the Database

Two options here.

  1. You can SSH into the dev server every no and again and dump the database into a file that you can download and import to your local machine. Use the commands above.
  2. If your host allows external database connection, create a user that has read only access to your dev site's database. You can then specify a host argument with a mysqldump command on your local machine and dump the database onto your machine directly -- I do this with media temple.

Example of mysqldump with a host.

shell$ mysqldump -p -u your_dbuser -h the-externa.db.host.com the_database > the-file.sql

You can also just log into your hosts PHPMyAdmin and export from there.

Syncing Static Files (Uploaded Images, etc)

rsync is your friend. It allows you to do delta updates from one location to another, including over SSH. In other words, you can use it to download only the files you don't have your local machine.


shell$ rsync -avze ssh [email protected]:/path/to/static/files/ /path/to/your/local/static/files/

Assuming your host uses passwords for SSH access, you'll be prompted for a password after running that command. If your host doesn't do that, eg. uses passwordless, public key SSH access, you'll need to jump through some hoops with a little shell script that uses ssh-agent:

#! /bin/bash

eval "$(ssh-agent)" # start ssh-agent user daemon
ssh-add /path/to/your/id_rsa # add your public key

rsync -avze ssh [email protected]:/path/to/static/files/ /path/to/your/local/static/files/

kill $SSH_AGENT_PID # kill the ssh agent

You can also use rsync to keep the static files in sync between your production and development servers.

The above is how I work with my personal sites and with a few client's sites.

  • Extremely comprehensive, thank you! Do you work with a team in the same way or are you a solo act?
    – KevDog
    Jul 5, 2012 at 23:28
  • Yup. Git is distrubuted version control, so anyone can work on their own private repo -- the only thing I might change if I was working with another dev is that we'd work in separate git branches, then merge changes into master (or an unstable branch, and keep master in clean, working order). As far as content, as long as content folks are working on the same staging/dev site, you should be good to go. Jul 5, 2012 at 23:31
  • I'm glad I found this, I often find myself working on WP projects with devs in other cities. One point of pain is syncing the DB between sites: full urls are hardcoded all over the place, and so they have to be search/replaced when going from personal dev -> shared staging -> production. Sometimes those arrows point the other way X( and the SQL dump becomes awkward to keep under version control. Someday, I hope to simplify this down to a simple grunt deploy that can talk ftp and mysql. Why WordPress can't just prepend the domain name while rendering relative URLs is beyond me.
    – Dan Ross
    Feb 1, 2014 at 7:06

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.