WP Engine and Atlas Headless CMS

WP Engine recently announced the launch of their Headless CMS hosting and frontend JavaScript stack, Atlas. This sounds really interesting so I took a look at their recent DE{CODE} 2021 conference videos on this topic to find out more.

As a little background we’ve used WP Engine at Studio 24 for a number of years, for enterprise WordPress hosting for some of our larger clients. We’ve always found their WordPress hosting solution rock solid, they have a bunch of very clever engineers developing solutions. When I attended a previous (in-person) WP Engine conference I was always surprised they hadn’t developed their own software to complement WordPress. Looks like that has now changed.

Atlas and headless

The keynote talk was a good summary by founder Jason Cohen on the reasons for investing in Headless. I liked the stat that 64% of enterprises are using headless. Many of us have been using decoupled architectures for years – just without calling it headless!

The key selling points are performance (with 10x page speeds than traditional WordPress), better security, ability to redesign without re-implementing your CMS, and developer freedom to work with any modern framework – as long it’s in JavaScript (for Atlas).

Performance and security I thoroughly agree with. Stripping back the frontend to only what’s required is clearly a great way to improve security and reduce attack vectors.

The ability to redesign a site using headless without having to reimplement your work in a CMS is also a big selling point, however, this assumes a solid frontend that does not also need to significantly change. I think this is the idea behind WP Engine’s Atlas JS framework (which credit to WP Engine is open source).

Developer preference for “modern tools” was mentioned a lot as a big benefit. I’m not so convinced here. Trends in software tools come and go, developers often want to use the next shiny thing, but businesses need to get things done and maintain websites over the long-term. Decisions on your tech stack should not just be down to preferences of your current developers. I’m not a big fan of JavaScript “eating the web” and I think it’s perfectly valid for websites and web apps to be developed in traditional (popular, well tested and maintainable) server-side languages such as PHP, Python or Ruby. If this is you, then WP Engine’s software based heavily on the JS stack is not for you.

Having to force front-end developers to code directly in JS is becoming a big issue in web development (see articles by Chris Coyier, Brad Frost). I think a full JavaScript stack is great if your team can support it. If it can’t then it can be an obstacle to business efficiency and can cause barriers to entry for people coming into the industry.

Front-end development is a highly skilled profession, which includes a wide range of client-side tech and skills such as usability, accessibility, performance, strategic thinking and device compatibility testing. Front-end developers need to know JavaScript, but they don’t necessarily need to be JS programmers.

I find it ironic one benefit of headless is decoupling, yet with the JavaScript/React approach HTML/CSS is tightly coupled with JavaScript. To the point pure HTML/CSS front-end developers can struggle to be able to work with it.

I thought WP Engine’s approach to solving the preview problem in WordPress was interesting. They use OAuth to get users to login to WordPress before they can view preview content, both helping authenticate to the preview site and authenticate the preview API requests to WordPress.

Benefits of exploring headless

Decode hosted a panel discussion on “Navigating the risks to reap the rewards of Headless WordPress” with perspectives from agency 10UP, the creator of WPGraphQL and WP Engine.

Phil Crumm from 10UP noted clients who are most interested in headless are those with a clear functional use case, those interested in security, or those who want more flexibility for the future. Content portability and flexibility is important. “While we don’t know what the future will look like, the decoupled architecture is probably going to be the best way to get there safely.”

Matt Landers from WP Engine talked about when is headless the right approach. His answer was: scalabilty, developer resources, security and data integrations.

He said “do you have the developers resources to do this? It’s a lot more developer heavy. You can’t rely on community built themes and plugins like you can in a traditional WordPress world. You’re going to have to depend on a development team to build that our for you. [maintenence costs] are coming down as we figure out how to integrate the front-end and back-end more seamlessly.”

Jason Bahl from WPGraphQL talked about the benefits of componentisation which could reduce production and maintenance costs in the future. Creating re-usable components that use GraphQL data fragments to output content that can be re-used on projects. I admit I’m not that familiar with how this works in React. We use Timber a lot at Studio 24, an excellent Twig templating system for WordPress from Upstatement. This is another way to support componentisation in WordPress today, though in practise it can he hard to actually do this across different client projects.

On the future of headless in WordPress Jason noted we’re “super early in this game. The more tooling we see built, the more adoption we’ll see.” There seems to be lots happening on this front across lots of different technologies, which is always great to see.

Gutenberg and headless

The final Decode talk I watched was “The Fast Track to Mastering Modern WordPress” with Rob Stinson of WP Engine and Carrie Dils. The talk focussed on Gutenberg and the future of full site editing that is coming to WordPress in 2021.

Full site editing allows users to edit and layout an entire site via Gutenberg, not just the content area but also headers, footers and the sidebar. Carrie went on to explain how full site editing themes works, moving from template files and template parts to “block template parts” which interestingly seem to be straightforward HTML files (which sounds good). It’s not clear to me if all the dynamic content is then in Gutenberg, which splits up all HTML code into React files.

More details on how this works is available at fullsiteediting.com, which notes HTML files may actually be saved as PHP files to support text translation and dynamic URLs. This feels like a pretty major architectural decision. I’d love to see a proper templating engine like Twig or Handlebars in WordPress! It would certainly help developer efficiency and a large breaking change like Gutenberg is the time to do it (if ever).

Carrie went on to show how the editing experience works in WordPress. It’s very similar to editing content in Gutenberg, allowing users to edit areas of the site such as the footer.

As for the timeline of all this, full site editing beta is available in WordPress 5.7 in March 2021. This is expected to be in WordPress core by 5.8 in June 2021, pretty soon! Given the disruption caused by the original Gutenberg release I hope this is a smooth and opt-in transition.

So does the Gutenberg layout need to look the same as the frontend? It’s not clear to me what the WordPress recommendation is on this – but it certainly feels like that’s what Gutenberg wants users to experience.

The obvious issue for headless is it’s decoupled, so laying out a site in Gutenberg cannot easily look the same as the frontend, if you’re using WordPress as a headless CMS. Which, to be honest, I think is good.

A CMS should not have to show content exactly as it will display on the frontend, but should give a good enough representation to the user to allow them to manage content effectively.

Rob Stinson then talked about making custom blocks, an area of great interest to me since I see this as essential for digital agencies taking up Gutenberg. Rob talked about a plugin called Genesis Custom Blocks.

The UI for adding a new custom block appeared to use Gutenberg too. This allows you to setup editor fields (that appear in Gutenberg) and inspector fields (that appear in the inspector sidebar).

I wonder how the custom blocks definition is stored, in the database or filesystem? All projects we use need to be stored in version control so we can deploy them across environments effectively.

When adding a custom block a PHP and CSS file is created which controls how the block appears in Gutenberg (when previewing rather than editing). This certainly makes it easier than embedding HTML in React. This is the same HTML and CSS as used on the frontend.

In the demo Rob noted the “styles on the frontend don’t perfectly match up what’s in the editor, but this can be fixed up.” In our previous experience we found it’s very time consuming, and thus not commercially feasible, to try to match CSS on the CMS backend with the frontend website. This is true for custom CSS themes which are the bread and butter of many digital agencies work. And I would have thought even more true for headless CMS setups where the CSS isn’t even shared.

One great point of the Genesis Custom Block plugin is you do not need to use the Genesis framework to use it. You’re free to use your own HTML and CSS.

We are still concerned about accessibility of the Gutenberg editing interface at Studio 24 and it contributed to our decision not to use WordPress for the new W3C website. I hope the Genesis Custom Block developers have considered this.

The aim of the Gutenberg project is to “make writing rich posts effortless.” That’s a mighty fine aim, but I hope WordPress can achieve this without breaking the web for others (be they accessibility users or front-end devs less comfortable writing HTML templates in JavaScript).

Final notes

Atlas sounds like a really interesting develoment from WP Engine and I welcome more tools in the area of Headless CMS. It’s sure to help more people get involved in this exiciting area of digital technology.

It’s a shame the name Atlas is so close to HumanMade’s Altis, WP Engine certainly would have been aware of this. However, Altis is software that extends WordPress more dramatically with DXP/enterprise features. Atlas, for now, is primarily a solution to help make better Headless CMS sites with WordPress.