WordPress is a great platform to develop in and for, especially since there’s just a small learning curve when starting out. This means that there’s lots and lots of people trying to figure this stuff out, which is both a blessing and a curse; the community is very vital and helpfull, but this also means that there’s a lot of best practices not yet known by many WordPress developers. Most of the WordPress developers now don’t use version control, don’t use anything else than FTP for deployment and one third of WordPress developers uses cowboy coding for every alteration. These numbers are pretty staggering compared to other platforms… Again; this has to do with the easy learning curve being both a blessing and a curse.
In these blogposts i’m going to be showing you our way of deploying websites from a local environment to a testing environment and finally to a live environment. Bear in mind; we’re not saying this is the best solution for everyone; you’ll have things you’d want to do differently… which is a good thing! We’ll start this part with the absolute basics; setting up a local development environment and using version control and hopefully we will convince some of you cowboy-coders out there…
You should always be developing locally. It’s a lot quicker, it’s easier to maintain and there’s no surprises when starting a project (have you ever had trouble with a hosting provider? Yeah.) We use MAMP PRO for our local development environment. There’s a free version (MAMP), but we’re using the pro version so we can have a little bit more control over the environment. For windows there’s XAMP and an bunch of other options. Check ’em out, install which feels warm and cosy and move on 😉
Next there’s version control; we use version control to create snapshots of our code so we can work together with other developers, roll-back any mistakes that might arrive and figure out where stuff goes wrong.
Git is definitely our weapon-of-choice in this case, there are a few others, but in this post we’ll be sticking to getting you on git. I understand that it’s a bit scary to look at git; it’s command-line stuff… Luckily there are more and more good alternatives that give you a nice UI for working with git.
Internalizing git and making it a habit instead of a chore is something that can take a while… please don’t be put off by ‘how long it takes’ and stick with it; you’ll thank me in the long run.
What to put under version control
A lot of people just choose to have there theme on git, but I really like to put the entire WordPress install under version-control. This is handy for deployment, but it’s also very handy when you’re collaborating with people; now you’ll at least all be on the same version of WordPress. There are a lot of people who disagree with me on this, and that’s fine… like I said last week: “i’ll be explaining how we do things, you’ll probably want to tinker with this setup and create your own”.
You still need to tell git to ignore some files though, otherwise things could go weary when deploying. In Git we do this with the infamous file. Here’s what ours looks like:
# Ignore this file and our wp-config file. .gitignore wp-config.php # Ignore everything in the "wp-content" directory, except the "plugins" # and "themes" directories. wp-content/* !wp-content/plugins/ !wp-content/themes/
This way your entire WordPress site will be under version-control except the wp-config file, the uploads- and updates directories in wp-content and it will also ignore any locally cached files if you are using a caching plugin. One thing I do like to point out; if you have other themes in your theme directory that the one you’re working on / are using; please remove the themes you aren’t using. Same goes for plugins you aren’t using, but that tends to change during development.
Now, developing locally and using version control are just the basics and don’t directly help you with deploying a WordPress site more easily, but it’s part of the process. We use a local enviroment to develop in, a staging development to test online and show the progress to the client (we recommend setting up a simple dedicated server for this) and then finally we push the code live. Transferring the code can be done by using SFTP, but i’m going to go into a much better way to deploy next week. We’ll be using the deployment tool Capistrano to deploy with just one terminal command; .