Were you at WordPresston, the first user group meetup in Preston? No? Well then, let me introduce you to static site generators. If you were there, let me recap the night for you. Also quick apologies to Phil Hawksworth for pinching his title, but when using WordPress it feels like the right name. He gave a talk at Wuthering Bytes back in August which got me talking more about using WordPress as part of a static site generator workflow to help make part of the process more dynamic.
So what are theses static site things anyway?
Static Site Generators are simply applications which bake data into Static HTML files. The idea being unlike WordPress, which generates content each time a user interacts with it, a Static Site Generator generates the content once, creating static HTML version, and then lets the server serve that content.
This means there is no need for specialist server infrastructure and no reliance on any dependencies once the content has been first baked.
The term Baked comes from a blog post by Aaron Swartz, where he talks about Baking vs Frying. The idea is that you fry individual components up for a single user, where you can bake multiple of the same thing at the same time.
Taking a new approach to working with Static Site Generators
I’ve previously written about using WordPress and static site generators in a blog post called “Blog like a confused hacker“, a small jab at the Jekyll announcement post. In that post I suggested that one possible solution for turning WordPress into a static site generator was to use a plugin like Really Static or StaticPress. However since writing that post I have been working more and more with the new JSON WP-API in WordPress. I have also played a bit more with Jekyll and so have started building up a set of tools to help people work with the two systems.
Jekyll, like WordPress, has plugins and they are split into 3 categories:
- Generators
- Converters
- Tags
Generators allow you to build in new functionality and control mechanism of what’s generated, so for example you can build a generator which extends Jekyll to allow categories or product pages. You can also use generators to select where you grab your data for Jekyll to create – in this case we are generating the content from the WP-API.
So our Jekyll plugin means that when Jekyll builds, rather than using a local file it makes a call to our WordPress instance (which maybe local or remote) and pulls from the WP-API to bake the static files.
Why go this approach over getting WordPress to generate the files?
- Jekyll and the many other static site generators are really quite good at their job, they are widely used and supported, in the same way the WordPress admin interface and features are (really) wildly used and supported.
- Front-end developers don’t have to touch WordPress, and while they still need to learn some sort of templating, in Jekyll’s case liquid, they don’t need to get into the increasing complex world of WordPress.
- With Jekyll acting at the front-end, you can merge and bake content from multiple sources.
- Can extend with all the plugins and other options available with Jekyll.
The downside is you are adding yet another dependency into your workflow, and you need to manage the workflow. Also you often need to maintain, at least partially, a dual theme in WordPress and Jekyll for previewing.
So how does all this work in practice?
Your WordPress install can be set up anywhere, including internally within an office firewall, as can the Jekyll install – though putting the two on the same box sort of makes sense in practice. The idea with this sort of setup is to limit dependency, so things like assuming a queue management system is available is a bit of a no no.
Consequently, I use a really simple setup of Presshook (plugin) (to create webhooks, on publish, update etc) and then let Jenkins listen for the webhook and run a build and deploy commands as two separate jobs.
So the only dependencies are:
- WordPress
- Jekyll
- Jekyll Generator Plugin
- Jenkins to build/deploy
When the Presshook webhook fires, Jenkins receives the notification, and runs a short bash script which fires a build command from Jekyll. Then the custom generator fires and makes several calls to WP-API pulling post content information, and then completes.
A second Jenkins job then deploys the newly baked static content wherever it needs to go. This might be a publicly facing infrastructure within the organisation, or it could be Github pages or Amazon EC2/Cloudfront.
Of course it doesn’t have to be Jenkins, and any build control or CI system would work, or failing that a couple of custom scripts to listen. Alternatively if you have a queue management system like Gearman in place, you can add it to a queue and just have a simple bash script running, to start the build process.
So why do this in the first place, this surely is not all in the name of performance?
I would argue the performance gains should be fairly minimal (depending on your setup). The real reason for doing this is to gain access to markets you could just not normally access with WordPress.
Rightly or wrongly (and obviously I will side with wrongly), WordPress has a negative reputation with System Administrators in larger enterprises. It is however often championed in larger enterprises by small minorities in departments, who are often then prevented from utilising WordPress by small minded but well meaning corporate IT. It’s interesting how reactions change when you explain that rather then asking for a public interface for WordPress site, you require an internal-only facing server and that the entire output will be static content.
This WordPressisation by stealth is one of the great side effects of this setup, as it does have considerable restriction and limitations with lots of the power of WordPress being unavailable. So as the marketing department (or many other departments), starts asking to make greater and greater use of WordPress within organisations, slowly WordPress moves from behind the firewall to in front of it.
What’s the future?
The future of Static Site Generators seems to be a good one. After a brief period of going out of vogue they seem to be back in again. By combing WordPress and Static Site Generators together we can reach new markets quickly and easily, make the workflow relatively simple for all concerned while neatly bypassing any compliance issues. It’s not a perfect solution and requires constant compromise especially when users in the company are use to have the full capabilities of WordPress at their finger tips.
Going forward one of the many projects I have been pondering is disposing of Jekyll within these stacks, and allowing WordPress to bake, removing Jekylll but keeping it’s features, including support for templating Front-End devs understand seems the next logical step, especially if it can be combined with allowing WordPress theme users to be able to use their skills so that no matter which side of the divide you come from you will be able to build stunning static sites. Bringing this functionality into WordPress while not trivial is certainly very doable especially when harnessing the power of WP-CLI it also allows us the opportunity to look at solving the “preview” issues discussed above though. Currently this is just at the ideas stage so if anyone would be interested in taking it forward let me know! Otherwise I might look to start tackling it in the near future.
Finally, just wanted to drop a quick thanks/apology to Phil Hawksworth for both stealing his talk title and repurposing some of the ideas from his talk. Hopefully he won’t mind to much.