Looking Back, Looking Forward: a Q&A on Headless WordPress
Al Jazeera is enjoying great success running a headless WordPress digital experience stack on WordPress VIP. But how did the media network arrive there? During a recent webinar, Digital Chief Technology Officer David “Hos” Hostetter discussed the challenges and benefits of migrating such a high-profile website to WordPress.
After the session, we asked Hos your follow-up questions, everything from their setup and back-end data model to what advice he has for other enterprises considering “going headless” and a migration to WordPress.
I think it really depends on the business problem you’re trying to solve. If you have a smaller site, I’d say just go with regular WordPress, if you’re okay with having the front end be the same framework. But, if you’re actually looking at it as a product, where you want an API layer, you have multiple different presentation front ends, and are concerned about scale and security, then I’d say absolutely yes, move forward with the headless approach.
Compared to other media companies, we’re actually a pretty small team, some 100 total. You can partner with other people, not necessarily doing it all yourself, but bringing in companies like WordPress VIP, companies like rtCamp and 10up, that have a lot of experience.
We used a lot of the core pieces within WordPress itself, because it’s easier to maintain. Specifically to Al Jazeera, one of the goals with the unification was having one common code base.
Would I do things differently? Of course. The way we originally had set things up made it a little bit more challenging, but we were able to get it under control. In this framework, things are always evolving, and so one of the important things is just to continue to adapt.
Initially there were multiple systems that we did integrate with, so over time it’s been pretty straightforward to add additional things. We’re currently looking at how we pull into additional wires and things like that, to make it easier on our journalists rather than having discrete systems. It’s WordPress, it’s a pretty straightforward model in terms of pulling things and pulling things out.
GraphQL has opened us up to a lot of different ways of doing things and provides a lot of different models. We were able to take advantage of that to integrate a new API system for our publications and redistribution of content, in a very quick and simple way.
The new technologies that are added are on top of WordPress, and make things really easy to move forward quickly.
We’re a worldwide corporation, so a lot of our scalability comes from the specifics of supporting and leveraging various additional providers. But the front-end setup and that headless component does give us a lot of ways to scale, in a different fashion than what you would traditionally do with WordPress.
The security of adding those other components was another area that we really looked at. But in our own internal testing, our scaling has been pretty phenomenal.
Yes, in terms of the migration, one of the things that really helped us was coming up with a clear strategy. When you’re coming off an existing CMS solution and trying to move to different components, it’s really trying to look at that and make the appropriate trade-offs because you’re not going to get everything in that first part on day one.
And so at least from a strategy perspective, our number one goal was do no harm to the existing sites. Number two was essentially optimizing for speed. And so making sure that we really are trying to focus on that from a delivery perspective so that when we went live, making sure that our performance bars were actually better than what we had previously, making sure that we left it better than we found it.
It’s always an important piece because a lot of times when you do these migrations they can actually end up looking worse or being problematic when unifying and standardizing. So we really tried to ensure that we were pulling things together and standardizing from a coding perspective and making sure that it was easily supportable, and then innovating going forward.
It was important to ensure that there really wasn’t any interruption in our service. And we were able to do that without doing too much. But it was also being really, really smart and understanding that sometimes to make these big jumps, you actually have to reduce some level of functionality.
But I would say overall, especially given that we were time-driven in a lot of things that we were doing, we were able to make huge strides pretty quickly. And it was interesting when we were first talking about this, the whole project, the company had tried this multiple times and it failed. And so we had been pretty good in terms of actually taking those next steps.
But part of this was also finding the right partnerships and trying to move forward with them as well and getting the right other people involved that actually had more experience, let’s say, with the WordPress side of things.
I’d say overall we’ve been pretty vanilla in a lot of what we’ve done. We actually did take a good look at Gutenberg, but at least from an Al Jazeera perspective, we decided not to move forward with that initially. And that actually caused some initial issues in terms of going back and forth on the dev teams. As far as the editorial side of things, the out-the-door was pretty straightforward.
We’re currently in the midst of upgrading to add some additional things that make it more… we call them interactive, but they’re more rich storytelling formats, and still trying to keep it easy. One of our goals internally is tied to this whole notion of elegant simplicity. And so I challenge my teams all the time to figure out ways to reduce rather than add.
In a lot of cases, what I want my teams to do is look and say, “What can we get rid of versus what can we add over time, and really keep it as simple as possible?” Because that simplicity is good because when breaking news is happening, you want people to be able to publish super, super fast. If you give folks too many options, what happens is it just causes more problems. So we make sure we have really, really nice streamlined paths here that allow us to go quicker.
But in that same breath, there are other things that we’ve done where you don’t want so many bespoke solutions out there. And so a lot of interactive teams have actually built these really, really kind of crazy customized solutions that maybe don’t apply to all the different areas. What we try to do is figure out ways to create solutions within WordPress.
Obviously, we have the other kind of mirrored side of going out to the different endpoints we’ve got, that allow them to be super creative. But it’s still within a framework, if you will. And so it’s definitely been something that’s been on our mind and it’s been really, really great.
I think if you were to ask the vast majority of our journalists, they would say things are better than they were previously. Like any place, you always want to go faster and have a lot more features sooner rather than later, and when we are trying to go out the door quickly, you incur a technical debt. We had some things that drove us to be a little bit more data-driven than I traditionally would’ve liked.
In doing so, that caused us to actually create technical debt. And so we had to go back and fix some of that and then fixing that it slows you down a little bit more in terms of some of the features. But what I will say is, as we’ve been moving forward and looking at integrating with other tools, we’re currently working with some other planning solutions.
We are trying to figure out what are those touch points and those interactions where you can actually have bi-directional feedback going from tool X to, let’s say, WordPress. And then understanding what goes out to the publication side. So it’s one of those areas that it’s important to move forward and continue to adapt and adjust.
David “Hos” Hostetter
Al Jazeera Digital CTO