For many, the concept of using WordPress as a static site generator would seem quite mental. Indeed there are many existing systems including Jekyll and Hyde (seriously) out there that do the job well and for well over a decade Macromedia was trying to convince us that the entire world world would be powered using systems like Contribute before we saw the light and moved to using real CMS’s.
Static Site Generators basically take a content management system’s content and combine it with a theme and generate static html pages. No dynamic content means they can be hosted more or less anywhere, consuming few resources to improve performance and, because they don’t require any specialist software, reducing the complexity of any stack.
What this means is that with Static Site Generator sitting on your laptop or a tiny $1.99 VPS somewhere you can create static content, which can be uploaded to any web server including hosting the entire assets on S3 for example. No databases, no requirement for PHP or Ruby on the end server. Just from a cost perspective static site generators seem like a wonderful idea and in 2012 they became the rage. So what’s wrong with them and when why do they appear to be a fad?
No dynamic content
Imagine going to your boss and saying, “Hey, we are going to use this great new technology to make everything lightning fast, secure and cheaper”. Great! Now explain to them, they can’t have a contact form, or an e-commerce system, the search system will need to be powered by a third party, and commenting is a no no. You get the point, each of these can be worked around, but people are used to their dynamic sites which can whizz and bang and make use of server side processing, they like have a contact form which the server processes and sends.
Static Site Generator works for a really simple site, for example a companies vanity site, with a local WordPress installed on their “intranet” (or more likely the sys admins laptop), providing them with a CMS allowing them to push content to a very small VPS which in turn is being proxied by a CDN.
I use WordPress as a static site generator on several projects, but again these tend to be more vanity sites, which rarely require updates, such as open source projects (using GitHub and Github pages for storage) or the numerous friends and family who want a website but don’t actually really want a website that they have to do anything with.
Why use WordPress?
It’s a pretty fair question, WordPress is complete overkill for this, and in truth I might be more comfortable using another software for this style of site (see my current setup below) in that I write posts within the post editor in Markdown, I’m utilising GIT as a revisioning system, so in many respects I am cloning Jekyll with the WordPress interface. But then I’m familiar with the WordPress interface, warts and all (For warts check out my friend Kimb Jones WordCamp Talk – Dashboard it Burns!). I don’t want to use yet another CMS when WordPress will do an excellent job for me. However the power of static site generator and WordPress comes into its own in what I describe as content farming. In this scenario, you have a single VPS with WordPress multisite install, allowing numerous sites to be managed from this central server across multiple teams. Rather than publishing to the VPS, the content is pushed to remote hosts. For small vanity sites and information portals the WordPress MultiSite option and user management combined with the ability to then use static generation provides the ability to create secure, fast, scalable system that can easily be automated more or less entirely (see content farming setup below). Now you can do the same with Drupal and there are dedicated Static Site Generators that are more then capable of doing all that but they don’t have the level of resources, the ease of training and all the usual benefits of WordPress – in effect, it allows the best of both worlds.
Blog like a Hacker! Just a bit of a confused one…
The announcement post for Jekyll was entitled Blogging like a hacker, and it introduced Jekyll as being a system that worked in the way developers think and on the whole it sort of does. Here is my WordPress take on Blogging like a hacker.
Local Install of WordPress: the setup is not dissimilar to the Skeleton presented in Structure your next WordPress project article but with an additional folder at the top level called remote_public_html which holds the Static site. This folder is a separate GIT repo which makes automated deployment easier and feels more semantically correct.
Because of the static nature of the site, the WordPress site doesn’t have much in the way of plugins but a couple that are really important for my workflow are:
- Markdown
- WP-CLI (technically not a plugin)
- Really Static Site
Most developers will be familiar with Markdown. It’s a lightweight language (think HTML on a serious diet) designed to provide minimal information regarding formatting of content. It’s used all over the web including WordPress.org where it powers the descriptions for themes and plugins. Markdown is simple easy to use and provides a good separation of content and templating while allowing the user to retain some control of presentation. The Markdown plugin replaces the standard WordPress editor and renders markdown as HTML. There are numerous markdown plugins available now; my preferred one is the one in Jetpack – but that is sheer laziness on my end.
WordPress CLI allows you to manage WordPress from the command line. I pretty much do 90% of my work via a terminal and as such it’s invaluable and it’s easy to extend via plugins.
Really Static Plugin is my Static Site Generator of choice. A couple of important points: it’s ugly, both visually and in its code. The site authors comments are in German, which for German developers will make a welcome change from translating English, but if you don’t read German good luck, Google Translate is fun! That said it is pretty straightforward to use, has a bunch of options and some add-ons. It also does have a good range of hooks, with possibly the most useful if you are extending or doing post update bits (like firing GIT for example) being the rs-write action. This fires once the static files have been added.
So how does my flow go:
I tend to not start in WordPress but rather in Sublime Text which is my preferred text editor, it’s heavily configured with several plugins including Markdown Editing and Sublpress. When Sublpress released it had a mixture of people claiming it was the best thing since sliced bread and a large percentage of people asking why! Why would you use a code editor to write blog posts, when WordPress has a perfectly good editor. The answer is I actually don’t know but I do. I find the combination of the Markdown plugins and my general familiarity with Sublime Text means I am happy writing posts in it written in Markdown. I can then use SublPress to create posts and pages on a local machine. Interestingly, and this is possibly a psychological thing with me, I don’t publish posts via Sublpress and always review and hit publish from within the WordPress dashboard. Likewise I always add extracts, choose categories and do my tidying within WordPress before publishing. So I: Write the post in Sublime Text, post a draft via Sublpress, check for errors and do my final edits in WordPress, hit Publish, which creates static files using Really Static Plugin
Having just swooned over the virtues of using Sublime Text and SublPress I have recently started playing with Mou. It has a nice split editor so I can see the rendered markup in real time (which is nice, though a little distracting on smaller screen) but doesn’t have an automated link between the editor and WordPress which means I’m currently importing posts via copy and paste. For that reason alone I’m not sure I would recommend it, though it has support for tumblr by sending an email, I’m sure that could be hijacked.
Once the static files are in my local folder, I simply add them to the git repo and commit and push. To save some time I have written a little plugin that uses the GIT.php class https://github.com/kbjr/Git.php to fire the various commands on a rs-rewrite action. Once the files have been pushed, the deployment system takes care of the rest and uploads it to the server. Then as it’s final post deployment hook fires a notification to the CDN network to flush the caches. The very last thing is a notification to HipChat to let me know it’s all done.
Sounds complicated? In practice once set up it’s no more complicated than using WordPress normally, so when I hit Publish, the site publishes and it just takes 30 seconds as opposed to being nearly instant.
Using GitHub Pages
If you are a WordPress theme or plugin developer, there is a fairly good chance you are hosting your plugin on github (at least the development version). Well why not also host the information site on their as well? GitHub provides GitHub Pages, basically static hosting, and using the above you can generate github pages on the fly. Instead of using your own git repo and deployment system, all you have to do is save and commit your files to gh-pages branch of your project, and you can even use a custom domain to tie them all together. You can do the same for a personal or organisation as well. So now if GitHub and WordPress are the 2 central points of your world you can bring them together.
Content Farming (Static to scale)
Above is how I manage several of my smaller projects which is fine (if quite geeky). For client sites or lots of informational sites I prefer this setup:
Single box (VPS or Dedicated). WordPress on the single box, set up with Multi-site, Really Static plugin enabled for each of the child sites Really Static does not work as a network plugin Deployment Script to Amazon S3
Really Static has an Amazon s3 plugin but I have never used it, as I tend to need to do some pre-deployment tasks. The idea however is each site static version is uploaded to it’s own bucket which has it’s domain name pointing to it see http://aws.typepad.com/aws/2011/02/host-your-static-website-on-amazon-s3.html for details on hosting static sites on Amazon S3.
The result is that you can have dozens of sites, running for peanuts, and clients can have their own admin area so for them it’s no different than using WordPress normally. I have made a couple of minor adjustments by creating a couple of filters to change the Wording on Publish/Edit to not link to the page (which doesn’t really exist) but which says they will be notified on publish. When the post is published an email is sent to them with the URL. It’s a simple touch but just prevents the inevitable support requests.
Static Site Generators
So there you have it, static site generators for WordPress have their place but it’s important to remember they are limited. By using WordPress as the CMS you have the ease of interface and lower training requirements of many site generators making it ideal for non technical staff to maintain a static generated site while still keeping costs down. A lot of the selling points bandied around are about security and performance, but for me it’s about scalability and ease of use. As a system administrator managing static sites is easy and with little downside to clients which means I can spend more of my day looking at XKCD and less of it WordPress and Nginx.
Update
Wait! You can’t update the post before it’s published Tim! Well, like a few of the posts coming in the next few weeks this post was actually written last year but never published. So just a few clarifications:
- When the article was written it was going on to a site that was using WordPress as a static site generator. timnash.co.uk does not.
- Why not? For the reasons outlined at the top. Basically, I wanted a contact form, email signups etc.
- My workflow has changed little, but I am using Mou for 90% of my writing, I pretty much haven’t touched Sublpress since I wrote the above article.
- Static Site generators DO have their place and I do encourage you to think about using them where appropriate.
- If you are not a WordPress user, then do check out Jeykl, running WordPress as a static site generator only makes sense if you actually use WordPress all the time.
Update 2 – June 23rd
I made a slight change after receiving a comment regarding dynamic content to explain when I talk about dynamic content I’m talking about content being generated via server side processing. I have also emboldened the rather important line that seemed to have gotten skipped in the comment reply. That most dynamic content can be worked around, be it comments, using disqus, comment forms via WooForms or even using REST API Calls.
Update 3 – November 11th
Just put in a link to my October Dynamic Site Strategies post, which has an alternative Static Site generator method, still using WordPress that I am now using instead of the one detailed in this post.
Image Credit: https://www.flickr.com/photos/55524309/