WordPress and the Headless Web

I was lucky enough to get the PressEd Conference started off this year. All the good stuff came later, and you can track it down using the hashtag #pressedconf20 or through the website. I got started with some much deserved love for the organizers whose vision for online conferencing was ideal for a pandemic 🙂 The seamless way the whole operation works is quite impressive, so thank you Pat Lockley and Natalie Lafferty for another awesome conference. I did not thread my slide tweets given they were pre-scheduled, so I’ll included them below.

A quick note on the presentation is that it is very much a work-in-progress and more akin to open reflection than a solid presentation—not to mention a chance to how far I could push my headless GIF game without going off the rails. I appreciate the PressEd folks letting me present this half-baked idea, but let this also act as a disclaimer for what’s to follow 🙂

As for the presentation, I tried to break it up into 3 parts. The first five slides being and intro and an attempt to explain what the hell headless web development is: 

The next 5 slides were devoted to explaining what Headless has to do with WordPress:

^No one really got this joke, but I thought it was hysterical when I came up with it. C’est la vie!

Finally, the last 5 tweet slides were made to given an example and explain Reclaim Hosting’s own interest in Headless as a way to both scale and syndicate content seamlessly, but I will discuss that in more detail on the blog as we get deeper down that road:

I do recognize that Headless WordPress development is a bit niche, it requires knowledge of APIs and javascript programming, and markdown. Not to mention chances are you would be depending on javascript frameworks like Gatsby, React, or something along those lines for building the static website (WordPress Calypso was exactly this idea). But my thinking was to introduce a fairly edge-case approach it is fairly new to me as well and talking about it would help me learn more. This is especially true given we are considering scaling and sharing some of Reclaim Hosting’s Domain of One’s Own documentation, not to mention Coventry’s Learn resources, but more of that in my next post.

That said, I was pleasantly surprised some folks had seemed to follow, and even had questions. Phil Barker asked about how you get things like contact forms, search, and other features on a static site not using the plugin infrastructure of WordPress, and that is a good point and a fairly significant limitation:


PressEd Conference also asked a question about Gatsby, and I pointed them to a webinar provided by Digital Ocean about getting up and running with Headless WordPress:

I was worried going into it that the talk would not be right for the conference, but in the end I think it hit a good balance of exposure to possible approaches while also acknowledging the limits of such an approach. I figure, like the GI Joe cartoon says, “knowing is half the battle,” so once you know you can see its value and/or realize it is overkill for most of your use cases.

This entry was posted in presentations, WordPress and tagged , , , , . Bookmark the permalink.

5 Responses to WordPress and the Headless Web

  1. Tom says:

    Oddly, your theme is showing two comment options in a stack. So who knows if this will work. (this is via the second one)

    I think you’re on the money with knowledge of possibilities being half the battle.

    Regarding Phil’s questions, you can do quite a bit more if you want. The sociology site is just a few dabs of javascript. With just the pure WP API– search, commenting, post creation etc. is available. There’s no real limit there, especially if you want to build something out using one of the frameworks. Also worth keeping in mind that a number of plugins have extensive APIs you can interact with. Gravity Forms is a good example where you could easily do contact forms etc. via the API.

    • Reverend says:

      Hey Tom,

      Thanks for the example and impetus for me to learn more about headless.

      Thanks for the heads up about my wonky Feedback form, and…

      Thanks for noting the possibilities through WordPress plugin APIs, that makes a lot of sense, and it would be interesting to think how the multi-channel publishing piece works through headless. Namely, we want to push documentation from one “authoritative” WP backend into 100+ portal for documentation so schools do not need to recreate the wheel, while let folks author and add in a kind of vetted approach. The idea of delivering various pages via API to a support page on their postal makes sure all documentation is up to date and allows it to be fast and fully online should anything happen to our site. It is a kind of pub sub hub model, and while we would love to make it go two ways by synchronizing changes from individual sites, the issues there still loom large—what if some folks edit a page with highly specific info that then is synched to everyone, so some level of permissions is necessary, and easier to give everyone a common editing space outside their portal for the white-labelled docs.

  2. Alan Levine says:

    Did DS106 predict this when it went headless? Oh that was a different chop.

    The headless CMS approach you describe seemed typically framed as authoring in one place to re-publish completely, elsewhere. There is some middle ground as Tom hints of not just lock/stock/barrel doing entire sites but for smaller tasks.

    While you can certainly grab all post content, the WordPress API gives you ways to get at anything under the hood- comments, authors, media. The WP REST API Controller plugin lets you expose and manage more endpoints (e.g. for custom post types, taxonomies) than what you get out of the box.

    Tom’s work inspired (and he lent help many times) for a project least year creating a lightweight HTML “navigator” that provides a way to see/filter newest content from a WP resource. I thought it was clever to provide a way for it to keep preferences in a cookieless manner. It’s not replicating the site, but providing a window into it

    I’ve also toyed with ways to pull SPLOT shared media into static html sites (which then become not so static). These are not any kind of game changer things like the VCU Sociology site, but it opens the possibility door when you can be thinking about ways to reach in and make use of content inside a WP site.

    I’d think for documentation, which is pretty much an outline organized body of content, a source in a GitHub/GitLab type space would work best (version control and the synchronizing comes in for free), where you can then have external sites sync to it, but most people abhor Markdown. I can see that a WordPress site, with the API reach in, could be set to be a source, even using something like JetPack that can store post content as Markdown.

    This stuff is pretty exciting, glad Reclaim is generating some R&D on how this might work.

    • Reverend says:

      Hey Alan,
      Headless R&D is still very early stages, but I think trying to figure out documentation and maybe port Coventry’s Learn would be a good focused experiment. I hope we can get that further down the road here soon, but as you know all too well the radio calls 🙂

  3. Pat says:

    Thanks for the love Jim, it was a great fit as WP gets all the love, but that loves is so unquestioned headlessness almost becomes a critique of WP itself.

    If, in the end, it’s just Gutenberg and JS, then I wonder if goddamitberg is a reverse takeover of WP. WP got popular imho on presentation and power, editting is a weird alternative timeline.

    Perhaps headless is the need phrase, whereas less admin is a better phrasing. Less securitybossies, faster, cleaner….

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.