Blog

Running WordPress Headless

I’m in the process of investigating how to get WordPress to run as a headless CMS. What’s a headless CMS? It’s basically a CMS that runs as a back-end content repository and then accessing the content through an API (Typically a REST based API).

It’s becoming popular for a few reasons, the main ones that I can see are:

  1. JS frameworks don’t have good support for CMS at the moment, yet they are becoming the dominant web frameworks in the industry.
  2. Device proliferation means that you need to write sites quickly for different platforms without having to port CMS tooling.
  3. CMS tends to be a one-trick pony; you can have CMS, or e-Commerce but you can’t easily/nicely have both from one solution.

Headless CMS makes sense, content is just data, right? We use RESTful APIs as data sources all the time, so apply the same principle to any web-site so that we can aggregate multiple content sources in a decoupled environment.

There is a rich tradition of content syndication, including technologies such as ATOM, RSS etc. Typically these are to do with meta data, though. For example RSS is the technology behind podcast listings. About 2 years ago, I was looking at how to achieve something similar in a brown-field development with Umbraco. There was good support to extend Umbraco via customer controllers, but nothing I could see that plugged straight in.

Looking now, and a quick Google search shows that many of the leading CMS providers now make APIs available to access content as data, rather than just through their templating front end. For example, the WordPress API looks pretty good (https://developer.wordpress.com/docs/api/getting-started/) and since this is WordPress, it makes sense to start there.

The WordPress API is publicly available. That’s good because it means you can get to this content just by following this link. I’m trying to think why that’s bad. My initial reaction is “because it’s my content, and I want to secure access to it”. For this page, it doesn’t make sense as it’s already in the public domain. But, if you host content which is more sensitive, or you want to exercise control over how and where that content is published (e.g. linking content to a product catalogue on an online store, which doesn’t make sense out of context) then that requirement becomes a little more important.

Good news for WordPress users, the WordPress API supports OAUTH2. I haven’t gone into that as the moment, but will be looking at it in more detail.

Another thing is that the content served via the API is JSON. Angular etc. are JS frameworks, and JSON is ubiquitous now, so consuming that content is going to be simple. Using jQuery, it’s a single AJAX call, redirecting the content in the response to a div in the page:

<div class="content">
  <div class="container">
    <div class="row">
      <div id="wp-content">Original value<⁄div>
    <⁄div>
  <⁄div>
<⁄div>
<script>
  $(document).ready(function () {
    $.ajax({
      url: "https://public-api.wordpress.com/rest/v1.1/sites/useyournoodle.biz/posts/?number=1&pretty=true",
      dataType: "json",
      success: function (data) {
        $("#wp-content").html(data.posts[0].title);
      }
    });
  });
<script>

I still need to have a look at how the HTML coming back from the API is encoded, but there are some pretty sweet plug-ins via NPM which can help.

So, headless CMS looks pretty straight forward from a tech perspective. I just need to look at how to integrate the data sources I’m using to present things in a coherent way. Should be interesting!