The prescience of format and delivery of #pressedconf20 is timely, thank you @nlafferty and @patlockley for continuing on with the third annual @pressedconf -it means a lot to many of us #bigfan pic.twitter.com/6awf3UqI8k
— Jim Groom (@jimgroom) March 26, 2020
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:
1) I'm Jim Groom and I'll be using the next 15 minutes to explore 3 things: a) what Headless web development means, b) how it relates to WordPress, and c) how it might be used in education #PressEdConf20 pic.twitter.com/xH1yhVA9Kf
— Jim Groom (@jimgroom) March 26, 2020
2) What does Headless web development mean? Like CSS removes styles from HTML or WordPress Themes separate design from content, Headless development splits
site presentation entirely away from where content is authored and stored #PressEdConf20 pic.twitter.com/RYj4Jj0ta5— Jim Groom (@jimgroom) March 26, 2020
3) So in a Headless setup folks would still author in a content management system (CMS),
but it wouldn't be presented on the web thru that system. Rather using APIs & Javascript
content would be converted to Markdown and presented as static HTML. That's Headless! #PressEdConf20 pic.twitter.com/6EH7h2hjDe— Jim Groom (@jimgroom) March 26, 2020
4) Why Headless? a) it can speed up a site given content resolves as static HTML b) static sites makes no database calls making them far less resource intensive c) you're not dependent on any one application, you can use any number of CMSs for headless development #PressEdConf20 pic.twitter.com/aqgWHPg23F
— Jim Groom (@jimgroom) March 26, 2020
5) That said, Headless may be most appropriate for sites that get significant traffic and are resource intensive. That said, the divorce of presentation from application makes it a good fit for multiple channels (web, mobile applications, etc.) #PressEdConf20 pic.twitter.com/H1tqUooGSP
— Jim Groom (@jimgroom) March 26, 2020
The next 5 slides were devoted to explaining what Headless has to do with WordPress:
6) What does all this have to do with WordPress, tough guy? Isn't this #PressEdConf20? Calmate, I'm getting there. Given WordPress powers > 30% of all web sites, there's chances are good more people are familiar with it as an editing tool (despite the curse of Gutenberg! 🙂 pic.twitter.com/3CSei5kicB
— Jim Groom (@jimgroom) March 26, 2020
7) WordPress is not only as easy and elegant an open source application you can find on the world wide web, but the fact so many people are comfortable using it already makes it an ideal authoring environment for a Headless CMS (but don't tell @btopro that) #PressEdConf20 pic.twitter.com/QXdUugJBzP
— Jim Groom (@jimgroom) March 26, 2020
8) If Headless can be thought of as separating the front-end of a site from its back-end, then it can be argued that WordPress is the most familiar and recognizable back-end in Higher Education #PressEdConf20 pic.twitter.com/HOF2tOMRB3
— Jim Groom (@jimgroom) March 26, 2020
^No one really got this joke, but I thought it was hysterical when I came up with it. C’est la vie!
9) For example, if your campus is already running WordPress and your community is familiar with publishing there (the case for many), going Headless to scale resources and publish to multiple channels would not require changing the authoring environment #PressEdConf20 pic.twitter.com/CYvzXkpXub
— Jim Groom (@jimgroom) March 26, 2020
10) While we've cursorily covered what Headless web development means and how it relates to WordPress, it might now be useful to look at an example and consider how it might work in practice #PressEdConf20 pic.twitter.com/mYASYmQm9U
— Jim Groom (@jimgroom) March 26, 2020
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:
11) VCU’s Digital Sociology's site (https://t.co/dGa6ZKU8rP) is authored using https://t.co/bMzgbXLCAr (a large WPMS), but that's not where the content is presented. On a different server there are HTML/CSS files that use the WP API to poll the Digital Sociology site on Rampages. pic.twitter.com/QAYpgEEnLC
— Jim Groom (@jimgroom) March 26, 2020
12) Should the WordPress site on Rampages ever go down (God forbid!), a cached version of the HTML site would be unaffected. What’s more, you could store a synced JSON file with all the database content on a server that would stand-in almost like a failover switch. #PressEdConf20 pic.twitter.com/rStmBtBtfZ
— Jim Groom (@jimgroom) March 26, 2020
13) You can read @timmmmyboy's thoughts on the impressive work VCU's ALT Lab (i.e., @twoodwar, @J_Everhart383, and Matt Roberts) has done to imagine their 35k+ site WPMS instance as an engine for a variety of complex projects on campus https://t.co/iEii2ItiE7 #PressEdConf20
— Jim Groom (@jimgroom) March 26, 2020
14) Currently @ReclaimHosting is exploring how we can use a Headless WP approach to share documentation across the various schools using Domain of One's Own in a more efficient and effective manner. This is early stages, but was the inspiration for submitting this #PressEdConf20 pic.twitter.com/L8xr0xDc1U
— Jim Groom (@jimgroom) March 26, 2020
15) So, that's it. Thanks for tolerating my low-level thinking aloud about Headless WordPress as we dig into this project. Hopefully we'll have more to share in coming months (or at next year's PressEd?), but until then I'm happy to respond to any and all questions #PressEdConf20 pic.twitter.com/oQP0Z3QaPM
— Jim Groom (@jimgroom) March 26, 2020
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:
That was really useful, thanks Jim. I'm thinking that headless might have advantages of being more secure and lower maintenance–that's why I have moved sites from WP to static in the past. Any thoughts on how to keep interactive parts alive, mostly contact forms and search?
— Phil Barker ? (@philbarker) March 26, 2020
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:
Definitely, there is an interesting webinar by the founder of https://t.co/gmatUVw7u7, @chrisoncode, talking about JAMstack using Headless WP and Gatsby , you can find it here https://t.co/Ir4K8etL7B #pressedconf20
— Jim Groom (@jimgroom) March 26, 2020
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.
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.
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.
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
https://cogdogblog.com/2019/10/corrleader-navigator/
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.
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 🙂
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….