A quick, free way to use continuous deployment with Wordpress
For the modern web developer, working with Wordpress can feel like stepping backward 5–10 years.
We are used to 12-factor apps, load balanced infrastructure and most importantly, continuous integration and delivery.
Wordpress was revolutionary, and still powers an enormous chunk of the web, but PHP/MySQL apps are no longer on the cutting edge.
Many of my clients still maintain Wordpress sites because:
- It’s cheap to host. Even the most basic £2/month hosting packages will run Wordpress just fine.
- It’s approachable. Even people who’ve never had their own website before have probably blogged on wordpress.com or something that looks like it.
Despite the advantages to non-technical site owners, I find the developer experience with Wordpress very poor relative to other stacks(for context, I mostly work with React and node.js). There’s nothing worse than dragging files across in FileZilla and crossing your fingers to see if it will work.
Setting up a proper continuous deployment pipeline is a quick, easy way to take away some of this pain.
What I mean by continuous deployment is: when I am developing a theme or a plugin, my work is tracked in git and Github, and will be built, tested and deployed on a working website without me needing to do anything manually. No more FileZilla.
Some hosting providers offer this as a premium service, but there’s really no need to pay.
Make sure all work is version-controlled
Whenever I build a custom plugin or theme, I store my work in a git repository linked to Github. I’ll .gitignore any folders that store the results of a build step, like compiled CSS and javascript, so that these are always up to date.
For CI/CD to work, I need to make sure that the repository is always the most up to date source of new code.
If I’m working with a client who might be tempted to make code changes on their website directly, I usually disable the direct plugin and theme editors from Wordpress. This is important because anything changed directly won’t be stored when the next version of the theme or plugin is pushed.
Set up a pipeline
I now use Buddy CI for all my Wordpress CI pipelines, because it has a generous free plan, and a simple, approachable user interface.
Buddy’s job is to watch your Github repository, and when you commit new code, it will come to life, building, testing and deploying your changes for you.
Although you can define your pipelines in code with a buddy.yml file, it’s really easy to use the web interface to define what steps to run in what order.
When I push new code to my repo, I normally tell Buddy to:
- Build front-end code with
npm run build. I use tools like sass, babel and webpack, so this step is a must have. - Lint PHP and javascript code
- Using FTP or SFTP, take the files you’ve built and put them on the website’s server in the right directory.
This is all free and will work with any hosting. All you need are FTP credentials.
Figure out your environments
It’s always a good idea to have a staging website where you can test out changes before dumping them in front of an audience.
Not all clients will pay enough for their hosting to benefit from a staging site, so I often set a temporary one up for them so they can review my work. If the client hasn’t bought hosting yet, try to find a package that offers a staging site.
With this set up, I’ll configure one pipeline to send things from the develop branch in my repository, and another to send code from the master branch to production. I do all my day-to-day work on develop and only merge changes into master when the client has reviewed things.
Have fun!
