We Said No to a CMS & built a Static Website with Jekyll

For many years we have been working with and implementing content management systems (CMS) because of the great flexibility, usability and independence it offers our clients. However, such flexibility and power is not always required and one should carefully consider the benefits of using a CMS against both the cost of implementation and the ongoing maintenance such as security updates. Because some sites are not critical to many businesses on a day to day basis, such maintenance can occasionally be dismissed, not to say outright neglected. Learn about the importance of maintaining websites built with Open Source software.

What our client encountered

Recently, we had a client come to us with a WordPress site that had been hacked because it wasn’t kept up to date with the latest security releases. This was not their corporate site, but a small blog used to showcase their corporate culture. Given the non-critical nature of this website, a monthly maintenance contract to keep the site up-to-date with the latest security patches didn’t provide them with a good enough ROI, and they initially decided against it.

We advised that fixing the hacked WordPress site without having a maintenance plan in place would not be the ideal solution -- it might get hacked again and again. Instead, we proposed that they replace the CMS option with a "static" website. We turned to an open source static site generator and proceed to rebuild their site with Jekyll using a purchased theme template.

What is a static site?

Your web browser (Chrome, Firefox, Internet Explorer, etc.), is equipped to solely render HTML, CSS and basic Javascript, regardless of the system used to generate these web pages.

Like 2001

Content management systems like Drupal, Wordpress, Ruby on Rails and others use server-side languages like PHP, Node and Ruby to perform complex operations, such as communicating with the database, encrypting data, dynamically aggregating content, etc. However, these languages cannot directly be rendered by browsers. Instead, they need to be interpreted by a server that will transform the scripts into HTML, CSS and Javascript and send this back to the browser to be displayed. The dynamic and complex nature of the server-side languages and the technology used to interpret and support them makes them vulnerable to malicious attacks.

Static page

A static web page is a website in its simplest form. When creating a static site, you literally create these HTML documents as opposed to, as explained above, instructing the CMS how to build these pages using complex server-side scripts. In other words, the HTML code that is created for a static page will be what the site visitor sees. One can now understand why static websites are generally more secure than dynamic systems using databases.

Static Site Generator

Building a static website, even for someone who is familiar with the document structure and knows HTML/CSS, probably sounds like quite the task: every time you want to create a new blog post, you would need to create a full HTML page. As one can imagine, these pages would have a lot of repetition: if you have a logo and some navigation at the top of the page, this would have to be added to each page you create. Additionally, if you want to update a navigation item at some point, it would have to be updated across all pages. When working with a CMS, we have gotten used to updating items in one place and then letting the system take care of the rest. So what can be done when building a static website while keeping these silly repetitive tasks down to a minimum?

Static site generators to the rescue!

Static site generators help us make the best of both worlds: they utilize robust programming languages to automate the repetitive parts of building a website, but ultimately, they output a static website that does not have to communicate with the server or a database.

Static site generators have two main components: template files and content files. The template files hold the repetitive items (logo, navigation, etc.) and also have commands that are designed to pull in content like “insert blog post here” or “insert a listing of 10 abbreviated blog posts here”. The content files are simply files where you add your content in plain text. Once we have our content and templates in place, we tell the generator to build your static site, and after a few seconds, basic HTML, CSS and JavaScript is returned and can be served to the browser. As content editors add new posts and update content, simply building the site again and again will publish content in an effortless manner.

Back to our client needs

Migrating from WordPress

In the case of this particular client, we has historical data that had to be migrated from the old WordPress site. We were dealing with approximately 400 blog entries, so it was imperative that we have a way to automate the migration. A simple migration script allowed us to copy the entries to a content file quickly and successfully. However, as with any simple migration script, some content was not perfectly migrated and some final minor cleanup was needed.

WYSIWYG > Markdown

When working with a content management system, many content editors are used to completing form fields. In the case of a blog, the body area usually has a helpful text editor (aka WYSIWYG editor). With Jekyll, content editors create content files using the markdown syntax, as illustrated below.

File name: 2015-07-02-my-blog-title.markdown

--- layout: default title: My Blog Title type: post date: 2015-07-02 16:00:00 image: 579_a.jpg categories: summer, fun, activities author: Jane Doe bio: I write blog posts! --- {: .alignleft } ## Header 2 ### Header 3 #### Header 4 Your first paragraph Your second paragraph * A bulleted list - alternative syntax 1 + alternative syntax 2 - an indented list item 1. An 2. ordered 3. list [File Download](/files/X.pdf)

Yes, this looks a little more like coding than pure content creation, but think of it like this:

Everything at the top, between the two sets of “---” are like the form fields you would have in your CMS. Instead of entering your data into a form field, you simply enter your information after the colon. Everything below the last “---” is used as your content. Here you can format headings, lists, links and more. Instead of having buttons to format title and lists, you will learn to use simple special characters to define these styles. For example, a level 2 heading is defined by placing “##” in front of the title. These characters do not get rendered. Instead the static site generator knows to wrap this content in the appropriate "h2" markup.

Client Control

With a CMS, content editors are used to being self-sufficient when they want to add and publish content. In the context of a static file system, the content editor is not inputting data directly onto the website, and there needs to be a way for the content editor to get the markdown file they created on the server. One way could be via FTP or by using Git, but this will require training, documentation and support. Our ideal approach is an integration with Dropbox.

Integration with Dropbox

What is Dropbox?

Dropbox is a service that allows you to store files in the cloud. Dropbox, and other similar services like Google Drive and Box.com, also provide an application that allows you to add a folder to your computer that will automatically communicate with the cloud-based application. This means you can add/edit/delete files in this folder on your computer and it will automatically communicate with the cloud-based application and update your files in that location as well.

But here is the fun part: you can also install a Dropbox folder on a server that hosts your website.

Adding, Editing and Deleting Content... you can do it all!

Content editors are given access to a Dropbox account that houses the folders they will need to update content. Typically this consists of a posts folder for their .markdown files and an images folder for supporting pictures. Content editors can upload new files to the Dropbox account either through the browser or by installing the Dropbox application on their computer. We then configure the same Dropbox account on the server, which will automatically pull in updated files as content editors make changes.

Automatic Rebuilds

While this gets the new content to the server, as we covered earlier, the static site still needs to be generated before this content is publicly visible. For this, simple scheduled automated scripts can be put in place so that no human action is required to publish content on the website.

Pros, Cons & Considerations

Site Maintenance

Static sites have lower Maintenance Costs. As we mentioned above, a static site will not require security updates like an open source content management system.

Content Management Systems give us more robust functionality "out-of-the-box" but need regular security updates.

Consider if the functionality that is normally built into a CMS is required. What are the development costs of mimicking this functionality with a static site generator? If functionality needs to be built with a static site generator, do the development costs outweigh that of a CMS maintenance contract?

Dynamic Content

Static sites have to work within the limitations of static content. Having said that, you can achieve certain dynamic functionality with the help of third party services. An example would be using Disqus to manage commenting.

Content Management Systems typically provide a user login/authentication system that allows you to provide dynamic user content. We are seeing this more in modern day websites and applications that ask visitors to create user accounts. Whether it is to buy products through an eCommerce store or bookmark your favourite articles, these customizations can increase engagement on your website.

Consider if dynamic content is needed and can it be achieved with third party services? Apart from administrators and content editors, does your site require visitors to create accounts? Users may need a custom dashboard or you may want to show custom content based on their location. With this dynamic content, a CMS may be a better starting point.

Speed and Flexibility

Static sites are fast & cheap. Page load times with static sites are incredibly fast as no communication with a server is required. Hosting costs can be as low as $0 if host your files on GitHub Pages. Again, this is possible because there is no communication required with a server.

Content Management Systems provide great flexibility, but they do require a server with resources required by the CMS. These additional resources come at a cost. Performance tuning is another area where extra development dollars may be required to speed up how quickly the content will be rendered for the visitor.

Consider the level of content control you truly need on your website. Can you pare back the content that needs to be configurable and go with a static site generator? With this approach, you may need to get your developer involved to edit something that would normally be configurable through a CMS sometime in the future. However, that cost could be minimal when compared to the savings of a simpler hosting plan and lower development costs.

Technical Expertise

Static sites require content editors to learn the markdown format. Is this going to slow down your workflow or act as a deterrent?

Content Management Systems provide rich text editors. Adding content can feel like editing a Word document which can provide a better editing experience.

Consider the current content publishing workflow in your organization and talk to those that would be affected by this change.