Ben is a lifelong Nintendo fan who likes to build websites, and make video games. He buys way too much Lego.
When I wrote about the things I had learned from releasing 20 WordPress themes, I mentioned that I had automated as much as I could. One of the things I automated was the build and deployment process for my themes – and so I thought I would write about what I have done.
Before you see this I feel I should add a disclaimer. This is the first project I have used Gulp for. It’s also the only project I use Node for. And I work on my own. As such I don’t know if I’m following best practices or doing things in strange ways. However I do know that using this has saved me days of work and allowed me to release theme updates much more often – so I don’t care. That said – I am always open to feedback so if there’s anything I can do to improve this – please do let me know in the comments! 🙂
The setup I have is a bit convoluted. I have a bash file that runs a series of gulp commands, and a small handful of command line commands. I also have a couple of PHP scripts that get executed by gulp. In this article I am going to show the bash file I use, and explain what each section does. In future articles I’ll show the code for the Gulp commands.
Below is the bash file I execute to do a theme update. Obviously I can also run each command individually if I just want to do one or two different things.
Currently running the build file takes about 10 minutes to complete so it’s not something I do often – maybe 4 or 5 times a week, but this is still considerably more often than I did them before.
10 minutes is a long time for a script to run, however the work it does saves me a good few hours of manual effort – and once it’s running I don’t have to do anything.
Each time you run a gulp task on the command line it tells you how long the task took to run, but since I am running a lot of tasks I thought it would be interesting to know how long it takes to run everything. So I reset the timer here, then display it at the end.
Generate Granule Documentation
Granule is my starter theme – it’s like _s but specific to the way I like to work. I am use PHPDoc comments extensively throughout the theme, and am currently using APIGen to create documentation. To be honest the docs aren’t that useful at the moment since APIGen doesn’t support file docs – but it’s the best I’ve found so far. I’m considering making my own documentation generator, but that’s a story for another time :).
Rebuild Granule SVG
The Granule SVG is an SVG sprite that contains lots of different svgs. This command compiles those source svg images into a single sprite so that they can be referred to throughout the themes.
This command generates the WordPress rtl.css file. Currently I don’t do all themes automatically but I am slowly working towards adding them all. The process is automatic, but it’s not perfect so I need to tweak the standard css to make sure there’s no bugs – which means thoroughly testing the themes. As such, all my new themes will have auto rtl, and my older themes will get it as I can go through and test them.
This is a new addition, and it’s already caught a few problems I hadn’t noticed before. It checks the translation text domains to make sure only one is used. A few times I’ve been caught out when copying and pasting code between themes/ from tutorials and have forgotten to change the text domain. It’s a nice safety net.
Export theme to theme updater
This is the theme build process. By default all my themes are created as simple themes for wordpress.com. This command cleans them up (removes LESS/ SASS files), adds extra code (like theme auto updates, and soon WooCommerce support), optimises any images in the theme, zips up the theme files, and updates the theme version database so that auto updates check the new version number. In addition this is the task that uses PHP. If I knew more about NodeJS then I suspect I could use that instead, but since I am happier with PHP it saved me some time to use that.
It’s one of the most complex gulp tasks I’ve made and saves me the most time.
Generate Child theme zip files
Take the generated theme zip files from the directory of exported themes, and then combines multiple theme zip files (parent, and child) into one zip, for easier distribution.
Build themes bundle containing all themes
Create a single zip file containing the latest versions of all theme zips.
Deploy theme to demo.prothemedesign.com
In the old days, I would setup the theme demo site and then leave it. It was too much hassle updating the theme demo code every time I changed something, so it only got done once or twice a year. Now I use gulp and rsync to update each remote theme directory and my demos and always up to date – automatically.
Deploy theme packages to theme update server
This uploads the theme zip files that were compiled above to the upload server so that they can be accessed by the auto update code that’s been added to each theme.
Update Granule github files
You know Granule, that starter theme I mentioned? It’s on Github (but I haven’t told anyone about it yet). This command copies the files over to my local Granule repository so I can commit the changes.
Update all PEAR packages
PEAR is a PHP Extension and Application Repository. It’s used to install and manage PHP extensions. I use PEAR for a few different things, like PHP Code Sniffer, and running this command makes sure that I keep all the packages up to date.
So that’s everything, although I periodically add new things. Over the next few weeks I will go through the different sections and show the code that powers them.
If you have any feedback on any of this – including other things you think I could automate, then I’d love to hear them.