#192 – Joshua Bryant on How Dow Jones Is Supercharging WordPress Editorial Workflows

[00:00:19] Nathan Wrigley: Welcome to the Jukebox Podcast from WP Tavern. My name is Nathan Wrigley.

Jukebox is a podcast which is dedicated to all things WordPress, the people, the events, the plugins, the blocks, the themes, and in this case, how Dow Jones is supercharging WordPress editorial workflows.

If you’d like to subscribe to the podcast, you can do that by searching for WP Tavern in your podcast player of choice, or by going to wptavern.com/feed/podcast, and you can copy that URL into most podcast players.

If you have a topic that you’d like us to feature on the podcast, I’m keen to hear from you and hopefully get you, or your idea, featured on the show. Head to wptavern.com/contact/jukebox, and use the form there.

So on the podcast today we have Joshua Bryant. Joshua works at Dow Jones, helping power some of the world’s largest publishing sites, including the Wall Street Journal, Barron’s, and MarketWatch, all on a WordPress Multisite platform.

His background with WordPress started, as it does for so many, by inheriting a site and slowly peeling back the layers of what the CMS can do, from page building to infrastructure and custom workflows.

At Word Camp US, he delivered a presentation called Reimagining WordPress Editing: How We Embedded Gutenberg Into Our Product Ecosystem, which digs into how his team decoupled the Gutenberg block editor from WP Admin. And embedded it in a standalone React application, all while keeping content stored in a traditional WordPress database.

This episode is a journey into why time, down to the second, matters in the publishing world, and how headless solutions can address those needs.

Joshua explains how editorial workflows were rebuilt so that breaking news can be published, or updated, with lightning fast speeds, removing distractions and page reloads for editors, while retaining the full power and extensibility of WordPress behind the scenes.

We talk through the technical architecture, planning, editing, and rendering are split into separate applications with Gutenberg customized down to just two or three essential blocks, living outside the typical WordPress environment.

Joshua talks about the challenge of simulating the global WP object, keeping business logic and proprietary plugins intact, and interacting with the rest API for Instantaneous content publishing.

If you’re interested in headless WordPress, editorial workflows at scale, or how Enterprise newsrooms leverage open source tech for real world speed, this episode is for you.

If you’re interested in finding out more, you can find all of the links in the show notes by heading to wptavern.com/podcast, where you’ll find all the other episodes as well.

And so without further delay, I bring you Joshua Bryant.

I am joined on the podcast by Joshua Bryant. Hello.

[00:03:25] Joshua Bryant: Hi.

[00:03:26] Nathan Wrigley: Nice to meet you. This is the first time that we’ve ever met. We’re going to be talking today about, well, the Dow Jones website, but also about headless, I guess is probably the best way to sum it up. So strap in. This is going to be a tinfoil hat episode. I am also going to say at the beginning that this is an episode for which I am supremely unqualified. So I hope that you are going to be able to shepherd me and call me out when I ask a silly question. So let’s hope for the best.

The reason that I’ve got you on is because headless is an interesting subject, there’s that, but also the fact that it’s Dow Jones that you are dealing with, and the profound importance of that. The fact that, of all the websites I can imagine, there’s not many which have that requirement to be alive a hundred percent of the time. So that whole piece is going to fit in as well.

Before we get into that, would you mind just telling us a bit about you? I mean, we know where you work now, but other than that, tell us about your experience with WordPress and so on.

[00:04:18] Joshua Bryant: Right. So, I mean, I started, I think like most WordPress people started, I inherited a WordPress website knowing nothing about web development at all. And so I struggled my way through Googling, what is DNS? What does that even mean?

And the WordPress offered me the opportunity to grow, and there’s always something new to learn. So from day one, I started learning about building pages, and then themes, and then plugins. And then I got a job where I was building themes and plugins. And then I got a job where I was really working on the infrastructure behind it.

As I continue to grow, I keep learning that there’s always another layer to WordPress. And I think I’m getting close to the bottom, but that’s what I thought every layer. So I did a little bit of contributing last year when I was here at WordCamp, and I’m just excited to keep growing and keep learning more about the power that we have in that WordPress environment.

[00:05:18] Nathan Wrigley: Thank you for that. So you’re at WordCamp US, obviously, you’re talking to me, we’re in the same room. Presentation that you did or doing?

[00:05:26] Joshua Bryant: Did.

[00:05:26] Nathan Wrigley: Did. We’ll get to that in a minute. It was called Reimagining WordPress Editing: How We Embedded Gutenberg Into Our Product Ecosystem. I might read some of the blurb in a little bit, but first of all, how did it go?

[00:05:37] Joshua Bryant: I think it went well.

[00:05:38] Nathan Wrigley: Good.

[00:05:39] Joshua Bryant: Yeah. I told the story in the presentation that I teach teenagers a lot. And it was a couple years ago, I’m in the middle of a lesson and I looked down and nobody’s paying attention to me because one of the students had gotten so bored, he had started ripping apart his styrofoam cup and he had been eating it. He was halfway through eating the cup. Halfway through my presentation, I look and nobody had done anything sort of like that. So I felt like the presentation went well, people were paying attention. That’s kind of my benchmark.

[00:06:08] Nathan Wrigley: That’s a good one.

[00:06:08] Joshua Bryant: I think I’ve gotten better.

[00:06:10] Nathan Wrigley: So here’s the blurb. And I won’t do it all, I’ll get maybe through the first paragraph and hopefully, dear listener, it’ll give you some context for what’s going to come in the next 40 minutes, half an hour or so.

What happens when you take the Gutenberg editor out of WordPress? This talk explores how we decouple the block editor from WP Admin and the Loop, embedding it in a standalone React application to power custom editorial workflows, while still saving to a traditional WordPress database.

Now there’s a lot in there. And I think that subject would be curious if it was just, you know, the mom and pop website, but the fact that you are actually dealing with, forgive me if I get this wrong, dowjones.com. I don’t know if it is dowjones.com, but it’s certainly the Dow Jones.

[00:06:50] Joshua Bryant: So Dow Jones as an entity, a fun fact, they no longer own the Dow Jones market. They sold it. But they do own a lot of publishing websites. So they own websites like the Wall Street Journal, Barron’s, Mansion Global. We’ve purchased more, I don’t know if I can say any of the other names right now, but we own all of those entities and so they are on a Multisite.

And so right now our publishing system, all of our editors publish from those websites in our WordPress Multisite environment. And all of that, we can talk about headless, but all of that actually goes into this all knowing database in the sky, where our front end systems pick them up. So WordPress itself doesn’t render wsj.com. We have a mobile team that does that. One way, we have a web team that does it a different way, and they all read from this all knowing database.

But we use WordPress and our editors use it, we call it NewsPress, and we use it to publish all of our content. Our editors find it easy to use, and we like all of the features that WordPress offers. So we’ve leveraged the power of WordPress to do those things.

[00:08:03] Nathan Wrigley: Some of those names were really enormous entities. Did you say the Wall Street Journal, or?

[00:08:08] Joshua Bryant: Yeah.

[00:08:09] Nathan Wrigley: Yeah, I mean, these are ones that I’ve heard of and I don’t live in this country, so that’s pretty profound. So I guess they’ve got an incredible appetite for traffic, but also an incredible need to be there a hundred percent. Not this 99.8% of the time. This is 100% of the time, I’m guessing.

[00:08:26] Joshua Bryant: Right. And the topic that we’re going to talk about today, and it applies to all news, but when there’s breaking news, being first to market matters. Being 10 seconds ahead of your competitor when Taylor Swift gets engaged is an important amount of time when you’re sending out a push notification. Or in the case of MarketWatch, when there are going to be fluctuations in the market and we have editors listening in on board meetings, being able to send that information out and get that to our readers as soon as possible is the most important thing to our publications.

[00:08:59] Nathan Wrigley: So is this a project, or an infrastructure, let’s go with that, that you inherited or were you bought in to build this?

[00:09:06] Joshua Bryant: Both. In the most simple terms, I can explain it, we’ll say we have three systems. We have a React based planning tool. We have a WordPress editing tool, where we actually write the articles, save the content, control user permissions, lock and unlock posts. And then we have the front end that then takes what they publish and display it in any way that they need across all of our publications. So we have planning, editing and rendering. And those are three completely separate buckets that have been there for quite some time.

[00:09:43] Nathan Wrigley: So we’re at a WordPress event and we’re surrounded by WordPressers, so it is kind of a bit of a bubble that we’re in at the minute. Everybody in this hall, in this place, kind of would understand what you’ve just described. However, dear listener, hopefully I’m not besmirching you, but there’s going to be a bunch of people listening to this who, what you just said went completely over their head.

They download WordPress, they pay a few dollars a month to pop it on a host that they believe is reliable, and they know there’s a database somewhere but they’re kind of using the front end. And that’s all that they need to concern themselves about. Just explain in more detail what you just said. This React, this editing and this front end. What even is that?

[00:10:20] Joshua Bryant: Right. I mean you can think of them as three separate applications on your phone. You might use one app, like your calendar, to plan things out. That’s what our planning tool is. It essentially lets us coordinate with each other and say, hey, we need to have a steady stream of stories. And we also want to attach, our photographers are going to put some images in those stories, so we might add that to the calendar invite description. Those are the kind of things we do in the planning tool.

And then in the WordPress tool, it’s a lot like what anybody does in WordPress. We’re writing posts, we’re adding images, and in the case of the newsroom, they might do a couple things around SEO, and add some metadata that we want to show up on Google. And I think everybody should be familiar with creating posts.

And then a completely different system picks it up and says, okay, I’m going to show everybody what it looks like. And that part is not really important because that’s the headless part. But you don’t really need to understand that there’s another system that does this thing differently, to understand what we’re going to talk about as far as, we moved our editor into, let’s say, a very simplified tool.

One example that I like to think about is, when we have done this project, we did it very specifically for the newsroom’s needs. So we tailored it very, very specifically. But I like to think of the applications of, I like to collect people who have great quotes. When I hear a great quote, I’m like, oh, I need to write that down. I don’t want to forget it. I like to think of it as, I want to pull up something like Twitter or Bluesky, and I want to just type in a field, hit send, and then it publishes a post on my WordPress dashboard. It’s a custom post that says, here’s a notable tweet. And it posted it.

That way I don’t lose that and I can have it in my WordPress, which is where I keep most of like, I keep my recipes, and my notes, and my blogs, and everything that I want to remember. It’s like my personal online notebook. But now we’ve created a mechanism where we can kind of take that and extend it anywhere we want outside of just the WP Editor, and be able to pull something up and say, hey, there’s a different application. You type it in, you hit send, and then it all runs through WordPress itself.

[00:12:48] Nathan Wrigley: What are the reasons why that needed to be done? So just sort of going backwards a bit, really. Obviously that is what is possible, but why is just a default version of WordPress on red hot hosting not something that is suitable in this situation? What affordances does it get you? What performance does it buy you? What UI does it allow you to create that makes this possible? And I think you said you built your own proprietary system. What did you call it, press news or news?

[00:13:15] Joshua Bryant: NewsPress.

[00:13:15] Nathan Wrigley: NewsPress, sorry. Wrong way around. So, why? What are the limitations in WordPress that were unignorable that required this?

[00:13:22] Joshua Bryant: I don’t think there were necessarily limitations. We are talking about shaving seconds off the editor process. And so there are a lot of things in our WordPress system that we want editors to do before they publish a normal article. We want them to have certain SEO titles listed. We want them to have fallback images for headline videos. We are okay with the way everything operates inside of WordPress, but we’re talking about shaving seconds off by putting it, first of all, in a tool that the editors are already in. They’re planning their day, they’re planning their month in the planning tool. And it’s a single page application. There’s no page reload. It’s all in React. There’s no calling a database that we have to worry about.

We’re literally just pulling up the Gutenberg editor, typing out a breaking news or a market watch, we call them pulse, some update that we need to get to our readers. And if there’s a bunch of information that comes in, we need to be able to hit 10 posts with as limited information as possible and get it to publish all the way to the front end, and do 10 in a row as quickly as possible.

[00:14:37] Nathan Wrigley: So the raison d’etre there then is time. It’s all about shaving seconds off because in the industry that you are in, if you’re five seconds late, you might as well not publish.

[00:14:46] Joshua Bryant: Right. It’s time, and it’s also distraction for our editors. They don’t have the full editor experience anymore. They don’t have the sidebar, and all the tabs because we have a lot of stuff in our editor.

[00:14:58] Nathan Wrigley: Okay, so in this three step process where you’ve got the React, and we’ll talk about ripping out Gutenberg and pushing it to this React app in a minute. But we’ve got the React app where the planning is done, then presumably when the planning is finished, and I’m going to use the word publish, maybe it’s not publish, but you hit a button, presumably that pushes it down the funnel towards the WordPress install, which then pushes it to the front end. So there’s this kind of like one way cycle.

But the idea of the React, Gutenberg bit is that it’s fast, really fast and distraction free. There’s just no clutter. It’s just, you’re familiar with that interface. Because with the best one in the world, WordPress, there’s a lot of things going on. When you click publish, quite a lot can happen at that moment. You don’t want any of that. You just want publish. Boom. Done.

[00:15:39] Joshua Bryant: Right.

[00:15:40] Nathan Wrigley: Okay. So you’ve pulled the Gutenberg editor out of WordPress. And, okay, I think it’s important at this point to say, Gutenberg is an open source project. We’re mostly familiar with it sitting inside of WordPress, but it doesn’t belong there. And you’ve put it inside of this React app. How have you customised it to get it there, and what have you stripped out, what have you added in?

[00:16:01] Joshua Bryant: Yeah, great question because part of the reason we decided to continue to use Gutenberg instead of some other React tool is that we’ve already invested so much time and effort into the business logic around our custom plugins and around the workflow, and we’ve put so much into our WordPress environment that we asked ourselves, how can we maintain all the equity we have in WordPress and leverage the power of WordPress, but put it in a slightly different place where we can take care of all of our editor’s needs? And so that was really the driving factor behind, okay, we’re going to move it here, but we still want all the things we have there.

And so what we did is we limited the number of blocks. While we might have most of the Core blocks in our regular editor, we have the paragraph and list block in our planning.

[00:17:01] Nathan Wrigley: That’s it?

[00:17:01] Joshua Bryant: Yeah, because that’s all we needed. That’s all we needed. And we have a couple custom plugins that we’ve moved into our planning tool. For instance, in MarketWatch, if you’re writing a story about Target, you’re going to want to tag the Target company, and we call it tickers, the stock tickers. And that lets our front end know, hey, this is a story about Target, let’s put the real time stock ticker information into this article, so it’s not like, when I wrote it a week ago, this is what the the stock ticker looked like.

It’s, when I’m looking at it right now, this is the real time stock ticker data. We put a lot of time and effort into building that plugin for WordPress, and so we wanted to find a way to not have to rewrite any of that code, not have to redo any of that work, but take what we’ve already done and just move it to the planning tool and have it work in both locations in the same code base.

[00:17:55] Nathan Wrigley: So I’m just trying to understand what that looks like. So let’s say that I’m in this planning tool. Somehow I get to that planning tool. I don’t know where it lives, whether I’m on a desktop or a website, or an application which lives on Mac OS. I don’t know. I probably don’t need to know, but I’m in it. And it looks like Gutenberg, yeah? I mean it is Gutenberg. Everything’s the same, except you’ve got this tiny limited arrangement of blocks. So paragraph, list, and then a couple of others, bespoke ones which you obviously need.

So what happens then when I’m doing that planning and then I click, I’m going to use publish again, I don’t know if you’ve overhauled the UI to make it something else, but let’s click publish. What happens at that moment? Where does that go? And how does it fit into the whole flow that we talked about?

[00:18:36] Joshua Bryant: Right. So everything that you do in a normal WordPress editor, you can also do using this thing called the REST API. And they’re just endpoints that exist that you can call to do things like lock a post, save a post, publish a post. And so when we do anything like that inside of our planning tool and we hit publish, it just hits this backend location that says, hey, post number 1, 2, 3, I want you to do what you normally do WordPress, and publish that post for me. And it doesn’t have to load anything inside of WordPress, it just hits that endpoint and WordPress says, well, I know how to publish. Okay, I’m going to publish.

And we didn’t have to load the page, we didn’t have to hit the WP Admin. It just skips all those steps and says, okay, I’ll publish for you. And then that sends it off downstream and they all do their thing. So it’s essentially the same, we just skip some steps.

[00:19:34] Nathan Wrigley: Yeah. So again, just to emphasise, the whole point of that was to save time.

[00:19:39] Joshua Bryant: Yes.

[00:19:39] Nathan Wrigley: That’s fascinating. That’s fascinating that time is such an important commodity. I’ve never come across a scenario, I mean I just don’t live in that world. I don’t have a scenario in my head where the amount of time it takes to hit publish and wait for WordPress to do its checks and balances and what have you, or load it up and all of that. But those few moments is important enough.

So you build the React app, it looks like Gutenberg, you hit publish via the REST API, it goes to WordPress, but it misses out all the intermediary things that may happen, and we can get into that in a minute. And then it just hits, it just publishes it immediately.

[00:20:15] Joshua Bryant: Right.

[00:20:15] Nathan Wrigley: That is fascinating.

[00:20:16] Joshua Bryant: And the great thing about keeping WordPress in the loop there is that if there’s a breaking news article, we do as rapidly as we can. We’re going to publish that article. But now it exists in the WordPress database, and we can go back to it and do all of the things that we normally do, but it’s already published.

So it’s out there, but now we can go and, just like the regular WordPress editor, we can add images, we can add SEO data, we can do all of those things we’d normally do. We can post updates, but the post is already out there. So we’re no longer in a rush, but we still are going to make that story more robust.

[00:20:53] Nathan Wrigley: So I’m just trying to be clear, because in your, the blurb for your presentation, you used this phrase, which was custom editorial workflows. I think we just went through that. So React app, WordPress, it gets published, we’re on the front end. But then at that moment, any modifications, let’s say, I don’t know, there’s an update, somebody has to modify something about it. At this point, you’re in the middle step. You’re going to the regular WordPress site and you’re updating it in there. Have I got that right? You’re not back the first step.

[00:21:20] Joshua Bryant: Right. We’re doing all of that in the planning tool. And then if you’ve been to some of our websites or I think any news website, you’ll see, last updated, and it’ll give you a timestamp. That’s when you get that notification that, hey, this has been updated. It’s because we’ve gone back into WordPress and we’ve added more information that our readers are going to find interesting or important. And we sent it down and there it goes again. Version two is out.

[00:21:45] Nathan Wrigley: Is this kind of standard practice in the journalism industry to have something akin to this because time’s so important? Or is it something of an affordance that you can have because those publications are already so successful?

Because I’m imagining it’s not all that cheap to put that together and maintain. Presumably there’s got to be developers surrounding it all the time and making sure it’s updated and kept alive. So I was just curious as to whether or not this is typical or something that you think is pretty unique.

[00:22:13] Joshua Bryant: Well, I’ll tell you this. This is the first time ever in my career that I have tried to Google things and got zero results. So I don’t think that it happens a lot. I think it’s pretty unique. I know our parent company, they own a bunch of other publishing corporations and none of them have done anything like this either. I think this is something that we pioneered and that it’s great, it was very unfortunate for me to try to figure it out.

[00:22:38] Nathan Wrigley: Were there headaches along the way? Was it really quite a challenge? Have you learned things which other people listening to this podcast, they may think, okay, I need to talk to Joshua. I have a similar crisis on my hands. Was there a lot of learning along the way?

[00:22:51] Joshua Bryant: I think the main thing that I learned was that WordPress has a lot of really good documentation for using it the way that it should be used.

[00:23:01] Nathan Wrigley: The normal way.

[00:23:02] Joshua Bryant: Yes. And so if you want to learn how to use WordPress, the documentation’s great. If you want to learn how to misuse WordPress, there is not a lot of good documentation out there. And you’re going to have to read a lot of Trac tickets and GitHub issues and Slack threads and, you know, read through the code.

And so, yeah, I will say that, pro, WordPress, great at documenting, but if you’re going to do something out of the box like this, you’re going to have to find those alternate sources of documentation, which is just, and how they built it. That was a good lesson and a good learning curve. And I learned a lot about the contributor process through that.

[00:23:40] Nathan Wrigley: Yeah. Oh yeah, I’m sure you did. Did it deliver, or does it deliver in the way that was anticipated at the planning state? So when the stakeholders were sat down and the green light was given to this project, did it come out exactly as expected, or were there things where suddenly you figured, oh, we cannot do this particular thing? Maybe it worked out better than you had originally intended.

[00:24:00] Joshua Bryant: Yeah, so actually, we rolled it out for MarketWatch first and it worked, and they have not complained, at least to me about it. But it was so good that they rolled it out to wsj.com next, and we developed it in such a way that it would be very extendable. And when they rolled it out to wsj, I didn’t know about it. So it really was a seamless transition. Now we have two of our biggest newsrooms using it, and I think we’re going to roll it out to Baron’s next. I don’t anticipate having to do any work for that either.

[00:24:32] Nathan Wrigley: I find this so curious. I think you maybe made yourself fairly indispensable.

[00:24:37] Joshua Bryant: I wouldn’t go that far.

[00:24:38] Nathan Wrigley: It certainly sounds it. So let’s get into the sort of technical bits and pieces about it, because I’m reading, cribbing from my notes here. You mentioned in the talk, simulating the global WP Object. And whilst that sounds interesting and is no doubt complicated, what are the critical components of the doing that? How did you replicate it? What was the biggest challenge? Stripping out the editor and making it work somewhere else.

[00:24:59] Joshua Bryant: Well, that’s one of the great things that I learned about the way WordPress works behind the scenes. When you’re building plugins, you import a lot of WordPress packages that do very specific things. And my assumption was always, when I build my code, it’s putting all of those packages into the code in one file and then ships it to my website. And that’s how it works.

That’s not exactly how it works. The bundle process for WordPress actually pulls all of those scripts out for speed and efficiency. You don’t want 20 plugins to have 20 different versions of the same code. And so they’ve pulled all of that out and it just uses one version of that code. Whatever version of WordPress you’re on, if I’m on six three, it’s going to run the six three version of all of the scripts.

And so when we moved our code over into the planning tool, there is no six three in React. It doesn’t know that these scripts are supposed to be there, and so it was referencing this global object, this Global WP. And if you’re familiar with doing things in the console, it’s, you type wp.data.select Core Editor, and you get a bunch of stuff back, right? It doesn’t exist in React or in Gutenberg. And so that was our first hurdle.

What WordPress is doing for us, building this object that all the code runs through, we’re going to have to manually do in React. We’re going to have to import those packages and set them at the global namespace level just so that the WordPress code will run.

[00:26:38] Nathan Wrigley: And how challenging was that?

[00:26:40] Joshua Bryant: Well, discovering it was the challenge. Implementing it was the easy part. We went through many iterations of, why is it not working? How will it not communicate? Before we realised that WordPress is doing this for us. And then once we had that realisation, the implementation was rather simple.

[00:26:59] Nathan Wrigley: To me, that would’ve been quite a frustrating process. Going backwards and forwards there. Why isn’t it working? Why isn’t it working? And then sort of suddenly realise, oh, it’s not working because, as you’ve just described. Yeah, that’s really interesting.

But you are happy that you went through that process. There’s no bit at which you thought, okay, we’re backing out. We’re not going to use WordPress. We’re going to use some sort of custom CMS that you can buy off the shelf, any of that.

[00:27:22] Joshua Bryant: Right. Oh yeah. I mean, if you had asked me a week into my back and forth, I would’ve said no. And it gives me a deeper understanding of WordPress too, and a deeper appreciation for the decisions that the contributors made when they built it to make it efficient. I never thought about how the WP build process helps developers build efficient websites, even if they don’t really know what’s going on. You type in WP scripts build, and then a lot of things happen. But the developers don’t need to know everything that happens. It just happens. And that’s great for developers.

But when I went that step further and I’m like, why is this happening? I went down the rabbit trail of figuring out what does WP scripts build do, and how can I break it? I want to do something else with it. And then coming all the way back to realising, no, they’re doing it the right way, the good way. And now that I understand what it does, I can design our system to be in alignment with that.

[00:28:26] Nathan Wrigley: Yeah, it sounds like you kind of went full circle there.

[00:28:28] Joshua Bryant: Oh, I did.

[00:28:28] Nathan Wrigley: Yeah, that’s really interesting.

[00:28:30] Joshua Bryant: Circle, spiral.

[00:28:31] Nathan Wrigley: Yeah, yeah, I’m sure there was a few spirals. So without giving anything away, how do your stakeholders that need to be a part of the first stage, the planning tool, how do they get to that? Can they access that with their phones? Can they access that with their desktop? How do they interact with that?

[00:28:46] Joshua Bryant: Yes, two things are important for us. We want to be able to access it in the office, on a desktop, plan out things. But we also want our reporters to be able to give us breaking news in the field, wherever they are.

[00:29:01] Nathan Wrigley: Right. That was where I was going with that, yeah.

[00:29:03] Joshua Bryant: Right. And so that is one driving factor for the decisions that we make when we make these design decisions, and make these application decisions. We need to remove as many barriers from our editors to publishing.

And sometimes that’s, how can we reduce the number of clicks to get a full fledged story out the door? Or it’s, how do we make this work with as few distractions as possible on a mobile phone when somebody’s sitting in the back of a boardroom?

[00:29:32] Nathan Wrigley: Yeah. So available on everything, everywhere. Where there’s an internet connection, you can get to this.

[00:29:37] Joshua Bryant: Yeah.

[00:29:38] Nathan Wrigley: Yeah, okay. One of the curious things, and again, we’re going to go into the technical details here, so forgive me if this question is misplaced, because you specifically mentioned replacing Core / Editor with Core / Block Editor. I’m not really familiar with what that distinction is, but the fact that you mentioned that kind of gave me an intuition that there was something there. So why was that important? And you are going to have to go slightly gently on me cause I don’t really understand.

[00:30:01] Joshua Bryant: I will gently wade into the weeds here. When we’re building custom blocks in our process here, a lot of times we use the data stores. And there’s an editor data store, and a block editor data store. What does that look like in the WP admin? When you pull up a post the block inserter, when you hit the plus on the top left, or you hit add, all of the blocks that show up, that’s one part of the Gutenberg editor.

The big chunk in the middle is the second part where you do all your typing, you put your post, you add your images. And then the sidebar on the right, where you make adjustments, is the third part. All three of those components are the Block Editor. Everything that exists outside of that is the broader editor. Think of that as like a giant wrapper around the entire thing. That has like the save button, the publish button. It has information about the post and all of its attributes.

And so it has much more information. The Block Editor just needs to know what blocks exist on the page. The Editor needs to know about a much broader context inside of WordPress. When we moved the Editor, we moved the Block Editor. So the save button isn’t there. We’re not using that. We wrote our own save button that hits the API.

[00:31:23] Nathan Wrigley: Can I just pause you there? So when you say the Block Editor, you are describing the three things. The panel on the left, the central area where you create the content, and the sidebar on the right, if you like, where the settings for those might be. But not the wrapper.

[00:31:36] Joshua Bryant: Right. And we actually went one step further and said, we don’t need the left or the right. We just need the part in the middle. We want to make it as distraction free as possible and move it over. So we have the option to put the sidebar there, and the sidebar works, but we have chosen as a business decision, we don’t want it.

And since we’re headless, whether they change the font or the colour, none of that actually affects our front end. We don’t want editors to be able to bold and italicise and make all the text red that they think is important because they would go crazy. They think all my text is important.

So yeah, we moved all of just that middle piece, just that Block Editor is what we moved over. And we have a save button, and a publish button that don’t interact with the WordPress Editor, they interact with the WordPress API.

[00:32:28] Nathan Wrigley: The REST API pushing it to the regular WordPress site. Okay, and again, just harking back to what you mentioned a moment ago, when we began this conversation, I was imagining a different thing. I was imagining that you pulled the Block Editor in its entirety out. So I’ve learned something there. So this is just that content creation area.

And by stripping out the left, and the right, and the publish and all of those things, that’s where the time saving comes, is it? Is that where the few seconds can be shaved off because it’s the bare bones of what it requires to create some text on a screen.

[00:33:00] Joshua Bryant: Yes, exactly. Because a lot of times it’s headline, paragraph, send. That’s it for the first iteration of that article.

[00:33:07] Nathan Wrigley: So one of the questions that I had, which now appears to be not necessary, but I’m going to ask it anyway. I was asking about things like, for example, manually editing the content that you would make in the React app, undoing things, history, and so on. That’s not really what’s going on. You’re doing it this one time in the React app, then everything after that is happening in the WordPress website.

So the history and everything is stored in the regular way, the bolding, the italicising, the, I want to make it red, that’s all done posthumously after the fact, once it’s been published, or at least shunted via the REST API to the WordPress, you know, the database, the regular WordPress website. So that all happens there. The amendments happen there.

[00:33:49] Joshua Bryant: Right. And we still have access to all of the toolbar options. So if you want to add a link, you would do it the exact same way that you add a link in your WordPress post. So we have some of that available to us, but we’ve locked it down. Not because it won’t work, but because we don’t want it to be a distraction for our editors.

[00:34:09] Nathan Wrigley: So is there any type of content that, I’m trying to imagine a scenario where, presumably not everybody needs the React app. So for example, if I’m writing a piece about, I don’t know, gardening or something, you know, it’s really not time sensitive. I could write this next year and it’s just as important, or a recipe or something like that. Do I need to be in the React app? Or is that just for the kind of, the journalists out in the field who need things quick? So have you got like this two tier system of editing, the, I need it extra, specially quick, you are in React, but the gardening post is just done as a regular post?

[00:34:41] Joshua Bryant: Yes. And that’s the majority of our posts, are all regular posts, and they’ve had time to plan it out and gather their assets, which they do in the planning tool, and all of that information syncs over to WordPress. But they don’t do any editing other than our breaking news.

[00:34:58] Nathan Wrigley: Okay. It’s the breaking news React app then basically.

[00:35:01] Joshua Bryant: Yes.

[00:35:01] Nathan Wrigley: Okay, that’s curious. Sorry, this is sort of sidestepping slightly. So they just create text. They create text and lists and that’s it. Paragraphs and lists. That’s all they’ve got. And when they hit the REST API, does it publish automatically or do they hit some other editorial workflow where somebody more senior gets to look at it? Because I’m guessing in this scenario where Taylor Swift got married, you just want to go straight to front end.

[00:35:28] Joshua Bryant: Yeah. It goes straight to the front end. They have a paragraph and list, that’s for the core, but they also have some of our proprietary plugins that, like we have a correction, and we have a ticker inserter, and there are a couple ones that we moved over, like our byline. We have a author database, and so they can say, hey, I wrote this. And so that’s a block that we wrote, and it works in WordPress and it also works in the planning tool, but it’s very limited what they can do because that’s all they needed. So we said we’ll strip everything else out.

[00:36:00] Nathan Wrigley: Is it a common workflow then where the same author who’s written this really time sensitive piece will hit publish over there, it goes from React app, REST API, to WordPress, to the front end? They would then almost immediately, do they at that point let go of it or do they then almost immediately go back to the WordPress website and think, actually, do you know what, I do want that bit bold, I would like to underline that? So yeah, I’m just curious what that workflow looks like.

[00:36:26] Joshua Bryant: I think it depends on the situation. And so in one case, while it is a breaking news story, as long as we don’t convert it to a full article, we can make updates in the planning tool. So he can go back, we can edit that and say, well, I wanted it bold, I’m going to do it in the planning tool. But if you wanted to, you could also do it in the WordPress environment. When we say convert to an article, we mean, this was breaking news, but I’m going to click a button and that’s going to let other editors know, we’re about to make this a full fledged article.

[00:36:56] Nathan Wrigley: Oh, I see.

[00:36:57] Joshua Bryant: Yeah. Because a lot of times we have multiple editors working on the same article. And so we need to be in coordination, especially around breaking news. Hey, this is happening right now. I’ve pushed it out. I’m going to pass this off to you. Can you go in? Hopefully there are no typos, but fix any typos, or change the headline, or add SEO data. So they really work as a team, especially around breaking news and then pass that off to other editors.

[00:37:24] Nathan Wrigley: Yeah, I guess because you’re in the weeds of this, it’s so self-evident what this workflow is. It’s just for me, it’s so curious that there’s all these interesting little steps, and behind it all is this desire to save seconds. And it really is absolutely, this is nothing like a WordPress site that I’ve come across in the past. Hope you’ll forgive my ignorance for keeping asking the same kind of question. But I find that really fascinating.

So the gardening post is done on the website, the important timely post is done in the React app, and yet there’s a convert to, I don’t know, regular content or something like that, button that an editor can go in and, yeah, it’s wheels within wheels. It’s absolutely fascinating.

[00:38:01] Joshua Bryant: Yes. This is why I said earlier, there were so many business rules and so much time spent into building our WordPress system that we didn’t consider another tool very seriously. Because we have so much invested in there, and there’s so much power in the WordPress system that we’ve, first of all out of the box, but second, what we’ve built on top of it that we said, we need to leverage this in this use case here.

[00:38:28] Nathan Wrigley: Yeah. Honestly, I think we could probably spend all day talking about this, but we probably should move on.

I’m curious as to whether any of this knowledge that you’ve acquired building this, because I know that in the WordPress community, most people don’t do headless, but there is a hardcore of people like you who just love this stuff.

And I’m just curious as to whether the knowledge that you’ve gained in the building of this, whether or not any of that gets put back into the open source project, whether there’s a commitment on your side, on the Dow Jones side to make this available, to open up a repo, to give away the content, the way that you’ve done it, the knowledge that you’ve acquired along the way?

[00:39:02] Joshua Bryant: Yeah, I think that is ultimately my goal. I started a repo just to show how we moved Gutenberg. There’s a lot of proprietary stuff that I had to take out of there. This is just my repo at this point. It’s lacking a lot of the, how do you get a custom block to work over there, at this point? I want to continue to add to that, but I think I’m also considering what, does this do for the broader WordPress community? How can this be applied to help Core, or to help contractors, or to help people who have a lot of clients.

One thing I’ve thought about is, if we have clients who may be difficult, right? I think we’ve all run into people at one point or another that said, I don’t like WordPress. I’ve heard the word React. I want React. People say, React is cool, right? Or I want a Vue project, or I want it to look like this. I don’t want to go to WordPress backend.

This is opening up a whole different set of opportunities where we can say, okay, I’m going to throw together, I’m going to vibe code, which I hate, but I want to vibe code a one page React application, and rely on the WordPress API to give me database, to give me user management, post saves, revision history. You can use WordPress as its own complete system and then just slap React on top of it, and have the full Gutenberg editing experience and save all of your information and still do all the things that you know how to do in WordPress, and your client’s happy and they don’t know anything about it.

[00:40:38] Nathan Wrigley: It’s kind of like WordPress without the WordPress. It’s the look and feel of WordPress without the overhead of WordPress.

[00:40:43] Joshua Bryant: It’s the power of WordPress. And what I say is the power of WordPress at the speed of breaking news. But it’s the power of WordPress at whatever the client wants. And so if they want one thing, you can give it to them there. And if you have a lot of clients and you have people spinning up different interfaces, maybe it’s React, it’s Vue. You have eight different clients, you can put them all into one Multisite and you can use WordPress as the backend for all of them. And each application looks completely different, tailored to those needs, and it all just goes through the same old WordPress functionality.

[00:41:20] Nathan Wrigley: Yeah, I guess that the way the interface looks is kind of the key bit there. You could make it look like Gutenberg, you could make it look nothing like Gutenberg. It could be anything that you liked. Simple, complicated, whatever.

I’m guessing this is really enterprise stuff, though. I don’t think we’re ever going to be straying into, I don’t know, I’ve got a dog walking service and I would like to offer that in my town of 3,000 people. We’re not for that. This is kind of enterprise, publishing, big pharma, that kind of thing.

[00:41:46] Joshua Bryant: Enterprise or people who deal with a lot of particular clients. Or people who want to build something cool for themselves, like I want to collect quotes when I hear them. I might build that application so that I can just pull up my phone, send out something like a tweet. I can say, Nathan Wrigley said this. It was really cool. Send. And now it’s a custom post type on my website called notable quotes, and it’s just your quote attribution.

[00:42:15] Nathan Wrigley: Yeah, yeah. I guess the beauty of the open source project, and thank you for honoring the commitment there, hopefully we’ll get the knowledge distributed, is that the first time around you doing it, it would’ve been very expensive because you’re a developer, your time is valuable. So presumably all of that got wrapped into this project. The company that you are working for could afford that. But maybe now it’s going to be a slightly easier bridge to cross. And I guess communicating with you might make that a little bit easier. I don’t mean to open up your calendar or anything, but would you potentially make yourself available through email or Slack or whatever? And if that’s the case, where would people find you?

[00:42:54] Joshua Bryant: Of course. I would say that I would love to pass this off. I try to tell myself, when I do something new, I always say, this is going to be the worst it ever is. And so when I’m looking at this, I see a lot of potential, but I also realise that this state that we’re in right now is the worst this idea is ever going to be. And I would love for people to come and make it better, and tell me what I did wrong and tell me what I can do better. And to say, but what if we did this instead? And that’s the beauty of open source. We want to see it grow. We want to see all of the possibilities that we can do with this.

And so please, first of all, take it, run with it, make it better. And second of all, yes, I’d be glad to meet and talk with anybody about it. And if I could save somebody the two week spiral, or the two week loop, I would love to do that as well. So yeah, I will absolutely make myself available.

[00:43:47] Nathan Wrigley: Where can you be found? What’s the best place to find you?

[00:43:50] Joshua Bryant: The best place to find me would probably be at my personal email address, which is j b r y a 0 2 9 at gmail dot com. And that is a carryover from my college years, so it’s a little weird, but it’ll work.

[00:44:06] Nathan Wrigley: I’ll make sure not to put that into the text on the WP Tavern website, but it’s in the audio now, so hopefully people can find it. Anything that we’ve talked about, if I can find a link to it, I will put that in. So listeners, head over to wptavern.com, search for the episode of Joshua Bryant. That’s Joshua, J-O-S-H-U-A and Bryant, B-R-Y-A-N-T. Search over there and you will find all of the bits and pieces.

I’ll link to the presentation that Joshua gave at WordCamp US, and maybe that’ll be on WordPress TV by the time you come to consume this. Anything else that Joshua wants to send me, I’ll put on there as well. So, Joshua Bryant, thank you for shepherding me through something that was much harder to understand than I’m capable of. So thank you so much.

[00:44:49] Joshua Bryant: No, thank you. You ask great questions and I appreciate it.