At several of the WordCamps I attended earlier this year, the topic of individual WordPress development processes seemed to come up often—whether it was in regards to version control, coding standards, or just getting your feet wet as a new dev. As well, folks like Tom McFarlin, who wrote a great series about Professional WordPress Development, have been contributing to the discussion around this at length. I’ve heard encouragement from other devs several times to share “the way you do things”.
The following is the way I set up, develop, test, and deploy, currently. Two quick notes:
- A process like this is never final, and should only get better over time. This is a snapshot of a process I’ve found useful.
- I’m not suggesting that this is the right way to do things—it’s just the way I do them. Feel free to leave a comment if you have a suggestion or want to share yours!
Local Development Environment
I’ve been using MAMP/MAMP Pro for quite some time, with very little issues. I like that it’s self-contained, allowing me to use the native MAMP stack on OS X for something completely different, like working on Pardot.
Git‘s entered ubiquity within my workflow. Between all of its own features and the availability of needed resources (like WordPress itself on GitHub), it’s quicker and easier for me to let Git do the work. Although I do love GitHub, I use BitBucket for my development because of the pricing structure: GitHub’s is based on private repositories, whereas BitBucket’s is based on users. Since I’m really the only user for now, I can set up unlimited private repos on BitBucket for free.
Put on some Led Zeppelin and let’s dig in by creating a new WordPress site from scratch, using the command line (which is your friend).
We’re going to use the official, public Git repository of WordPress to download the files instead of clicking through folders. Why? It’s faster, and you can stay in the command line to get things done. For what it’s worth, I’m sure you could create a sort of shell script from these lines.
I wrote a shell script that performs these tasks for you (up until initializing the Git repo). It asks for a directory name, creates it, downloads WordPress, sets up your database, and even fills out your configuration options for you (including secret keys). It’s free on GitHub.
) with whatever works for you. Just make sure it stays consistent throughout this process.
git clone https://github.com/WordPress/WordPress.git git checkout 3.5.1 rm -rf .git
Now, let’s create the new database and give permissions using the command line as well.
../../Library/bin/mysql -uroot -p CREATE DATABASE .* TO 'root'@'localhost'; exit
Now, go create a new repo on BitBucket. It can be private or public, but grab the repo’s URL. We’re going to set up the
wp-content folder as our local Git repo, since anything we’re doing to a WordPress installation should be done within this folder. Don’t hack core. Let’s set it up, make our first commit, and push:
cd wp-content git init git remote add origin (i.e. http://localhost:8888/ -p/wp-content git add db-backups/
It will change your life if you’ve solely been using FTP to move things to a live server.
Once our files are uploaded, we’ll need to get the database updated. The way to do this varies wildly depending on your hosting, but you want to import the latest file in your
See how useful that is? It’s already there and ready for you.
Once you import, you’ll need to make sure all the URL’s in the database get changed from your local URL to your live one, or else your site will, um, not work at all. This is not as easy as a simple search and replace query because of serialized arrays and such, so I use the amazing Search Replace DB script, an open source piece of magic that does this for you. Upload it to your main parent directory (the one with
wp-config.php) on the live server and follow the instructions. Remember to delete it once you’re done! Otherwise, you’re giving someone pretty terrible access to wreak havoc on your DB.
Keep Working Locally
The next time you need to fix a bug or add a feature for the client, just overwrite your local files with what’s on the live server (if they’ve updated any of them) and do the same database-search-and-replace as above, but replacing the live URL with your local one. Do the work locally, test, and re-deploy. This keeps useful backups of everything for you and the client on a third-party server, as well being a useful emergency tool. Did a client accidentally break something editing a file? Push your most recent working commit from Git to get the site back up!
Do you have something you’d like to add? Have a question for me? Did I miss anything, or type anything incorrectly?
Let me know in the comments. Happy developing!