The decoupled or “headless” CMS is rising in popularity among developers because of its capabilities for innovation, flexibility, and future-proofing. Building WordPress-powered websites via the WordPress REST API and the Create React App is a relatively new, but very powerful phenomenon.

During the 2017 WP Engine Summit, Phil Crumm, Director of Strategy at 10up, and Weston Ruter, the CTO at XWP, discussed how to take advantage of headless WordPress, create meaningful user experiences, and harness all of the capabilities of a decoupled infrastructure.

How do we define Headless?

It can be different to define Headless because there are many varying perspectives. Often people mistakenly refer to other types of deployments as headless.

However, the common denominator for headless and WordPress is the REST API. There are also different variations of the separation of WordPress, the CMS, and the front-end. So how many people refer to headless is you have the WordPress front-end and back-end still on the same environment but the front-end is decoupled from the back-end. However, there are different variations. Headless “light” refers to when the REST API is serving all the content but the front-end isn’t very far away from WordPress.

Being completely Headless, however, involves disconnecting the front-end completely from WordPress.If using completely Headless WordPress, a lot of the things that WordPress would normally do completely out of the box become things you must do yourself.

The REST API is a powerful tool to help solve that problem; you can provide additional information to the front-end and take care of that more easily. Right now, the answer to how to successfully integrate, and what integration means is really based on the problem at hand and who you are. As a WordPress community, we need to try and make the platform more homogeneous if we want to help it develop beyond the traditional, single-model platform.

Breaking It Down

This represents a project involved a truly headless platform. WordPress is a platform for content to come in from a variety of third-party sources and merges it with first party editorial data and all the data is easily curated. The content is then spit out into another layer and served on the website via the front end developers.

One of the strengths of WordPress and Headless is superior content management. WordPress is an editorial interface that almost everyone in online publishing has been exposed to it at some point. Instead of creating projects from scratch, it’s a lot easier to build on top of WordPress and build one platform that does one thing really well.

Let’s look at some examples.

Beachbody and Headless

Beachbody a fitness company. Being a large company with many different endpoints for where their content goes, (including web, apps, TV sticks, etc) there need be much less coupling between the front end of their website and the data they were entering.

Beachbody wanted to keep WordPress as the CMS because it was familiar and proven but in order to lessen decoupling between the frontend and the CMS, they wanted to separate them. By separating them, WordPress can focus on delivering content and XWP could focus on developing the CMS. Additionally, other teams were involved in building up the website and the app. The project embodied headlessness by implementing a centralized content management system but also decentralized development.

Campbell’s + Pinterest and Headless

Often the utilization of headless takes the form of interesting applications that incorporate integrations to build using headless WordPress and create unique functionality. Headless WordPress creates possibilities for using WordPress as an application platform and can be used for projects that aren’t traditional publishing applications.

Campbell’s recognized the challenge of using Pinterest for recipes and cooking was that often times recipes could be unattainable for the average person. Campbell’s presented the idea of taking data from Pinterest’s metadata, in which ingredients and cooking appliances are found and combine that with information that Campbell already has. This way you are cooking with the simplest recipes and steps.

The process and platform work like this: you connect with Pinterest, it scans your Pin boards and it presents you with some recommendations with real recipes that are actually easy to make. Hence the name, Reality Check.

When you think about this from an engineering perspective, layering a couple APIs together is pretty straightforward. When you get into the nitty-gritty: settings management, API credentials, keywords, etc. the logistical legwork becomes tedious. One of the interesting things about WordPress, the Rest API, and custom post types is the idea that you can build a platform that connects a bunch of APIs in the backend and WordPress acts as an application layer for common functionality. WordPress takes so much of the nitty-gritty and simplifies it. It’s an easy platform for engineers to use and learn. Using the customizer, because it’s flexible and elastic, this project is scalable for the future.

The Possibilities of the Customizer

One of the things you get from WordPress for free is the ability to preview the change to a post or page. In a headless context, because the frontend is separate from WordPress you can’t preview things. In addition to that, WordPress (outside of the customizer), doesn’t allow you to preview changes to multiple content types at the same time. Previewability and collaborative revisions are something that WordPress hasn’t supported.

In regards to Beachbody, let’s say you wanted to create a whole new workout or product line. You’d have to create a new trainer, workout, and several custom post types. Even in a regular WordPress site, how would you go about doing that, previewing that so that stakeholders could review it, and then batching all these changes to go live together?

The customizer solves this and creates an ability to preview whilst still utilizing headless WordPress. It does that by using Changesets, released in WordPress 4.7. If you are in the customizer, everything stays in the customizer, until you hit publish. You can do everything you want in your site and everything will be bundled together into a Changeset. Once you publish, all the changes go live together. In this context, because those changes have a unique identifier, that allows you to make requests to WordPress and you’ll get a response that is customized according to what you have in the Changeset. This applies changes not only to your front end but also to the REST API and to applications.

With Beachbody, XWP, designed a customized post plugin, which allows you to manage posts and create any customized post type and data in the customizer. As well as the Customize Snapshots plugin which adds the ability to save or schedule a draft. These aspects, because XWP submitted requests, are now in 4.9 alpha.

Say you wanted to change the profile picture for Tony Horton, for example. You can do that in the customizer and preview it. The preview will load on the frontend of the site and include that UUID. The React frontend is made aware of that UUID. The application automatically, then, becomes previewable. Therefore, when you are making changes you can also see what changes are made in the REST API. From an editorial perspective, you can see what it’s going to look like and from a developer perspective, you can see how the code has changed.

If you have the UUID, you can give that URL to any stakeholder you might have (even if they don’t have WordPress) and they can preview any changes you might have made.

Two different models for previewing changes: web frontend at the top and application at the bottom. The common denominator with both is the Changeset.

For local apps, however, there’s more of a process because there’s no URL to and so XWP enabled a mechanism where you can enable a Beachbody customer as an entity. You can create a customer account (1, 2, and 3) and you can make some changes and link that change with the user. Then, you can login to an app as that user and then all the requests that go to WordPress will include that indicated user state and then the mapping can be done in that requests.

The last example includes the application StoryCorps, a nonprofit application in which users can record conversations with friends and family and preserve them eternally without fear of losing those memories. StoryCorps mission is to provide the platform to talk to each other.

There are a couple different ways to record: home interviews and conversations with interesting people (celebrities, WW2 veterans or anyone with a cool story). Then, there are a couple ways to view the content: on the website or via the mobile app. The platform ties all these pieces together using one application layer. It’s serving as content management system and as a confident application platform.

10up built out a mobile application that uses Ionic which renders a mobile version of your website with a couple different tweaks so you can provide for specific pieces of code for things like audio recordings. It gives you an application to go online and record this content and distribute it to the application. Regardless of the way you’re using the application, you’re still interacting with WordPress. If you were to create an account today and connect it to the WordPress REST API you have the option to upload to the cloud.

Wrapping Up

The underlying theme of these projects and the possibilities of innovating with headless is WordPress’ ability to be flexible do multiple things well at once. Whether you’re using the customizer, as a content storage mechanism through the REST API, or an editorial platform, the possibilities are endless. For the end user, they don’t care that it’s built on WordPress, they just want something that performs. And for the editorial team, they just want a platform for publishing that is familiar and do many things at once. Lastly, it’s still in the realm of affordability for most companies.

The post Innovating With Headless WordPress appeared first on Torque.

Share This