[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, bringing podcasting to Jetpack.

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 Rob Pugh and Tony Arcangelini. Rob and Tony are longstanding members of the Automattic team with extensive backgrounds in marketing, product, and software development. They’ve spent years building tools for creators, writers, podcasters, and everyone in between, and now they’re fully immersed in WordPress’s evolving podcasting capabilities.

If you’ve been looking for ways to run your podcast from your own WordPress site, this conversation is for you. Rob and Tony dive into the new Jetpack podcasting features, and why they made the leap from WordPress.com’s basic audio offerings, to a more robust, integrated solution, within Jetpack.

They talk about what makes WordPress and Jetpack such a powerful home for creators. The ability to bring your newsletter, blog, podcast, and all your content and communication under one roof, all while keeping ownership of your data.

We talk through the advantages of keeping your content out of walled gardens like Substack and Patreon, and the value of flexibility, whether that’s adding WooCommerce to sell merch or customising your site’s look.

Rob and Tony breakdown just how easy it is to start your show. Drop audio into a post, set your category, and let Jetpack handle the rest. From distributing your RSS feed to major podcast apps, to sending out newsletters, and automated social posts. They also get into how integrations with PocketCasts and Jetpack AI make content creation, transcription, and distribution smoother than ever before. Plus how WordPress is open Foundation promises you’ll never be locked in.

If you are a creator wondering how the next generation of podcasting fits into the WordPress ecosystem, or just want an easier way to launch and grow your show, 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 Rob Pugh and Tony Arcangelini.

I am joined on the podcast by Rob Pugh and Tony Arcangelini. Hello, both.

[00:03:23] Rob Pugh: Hey, how’s it going, Nathan?

[00:03:24] Tony: Hello, Nathan.

[00:03:25] Nathan Wrigley: Nice to have you both with us.

Today we’re going to be talking about something which is actually genuinely dear to my heart because we’re going on about podcasts. Yay!

I’ve been in the podcasting space for decades, and WordPress has been the place where I’ve done it every single episode. I’m entirely indebted to WordPress for the capacity to do all of the podcasting I’ve done. But I’ve never done it inside of Jetpack, because until recently, I don’t think that was possible. So that’s what we’re going to talk about today.

First of all, I’ll just go round the houses. I’ll start with Rob. Would you mind giving us just a quick potted bio of what it is that you do over at Automattic, Jetpack, whatever it is that you want to mention.

[00:04:04] Rob Pugh: Yeah, so I’ve worked at Automattic for seven years. I’ve been in marketing and now focused more on product, but I like to do a bit of everything. And I work mostly with tools for people that create stuff. So podcasts fit right in there, and we are excited to build out this feature.

[00:04:19] Nathan Wrigley: Nice. Thank you. Tony.

[00:04:21] Tony: Yeah. I’ve also worked for Automattic for about eight years now. I do software development, and so I have had firsthand in building everything that we’re talking about today.

[00:04:31] Nathan Wrigley: Okay, thank you very much.

Now, just before we started recording, I was on the call with Tony before Rob joined in and you labored the point, not labored, but you mentioned that you were in the sort of creator side of Automattic. I didn’t know that existed, but that to me is about the most interesting bit of any organization. You know, the bit where the musicians come, and the poets come and the writers come and the podcasters, and the videos and the YouTubers, and all of that come. I think that’s really interesting, and I didn’t realise there was a wing of the business entirely aligned to that. But I guess I’ve been schooled, and now I know. So podcasting definitely comes under that banner.

Okay so I didn’t know this existed, and I think it didn’t exist, but maybe Tony can redirect me a little bit here. Podcasting in the WordPress space, I think you could do more or less everything that we’re about to talk about inside of wordpress.com until recently, but now it’s shipped inside of Jetpack. First of all, I’ll just send that one to Tony. Is that true? Is this all like a port of things into Jetpack from .com?

[00:05:32] Tony: I’d say it’s a little bit more than a port. So we built a very basic feature of podcasting in WordPress.com to offer WordPress.com users. It was very basic. It was just the feed. Basically what you see in the free offerings right now. The ability to drag an audio into a post and for that post to then become a podcast episode. And then we had a curated RSS feed that was available. And then very basic, the core basic iTunes tags that are needed to be able to be picked up by these apps.

That existed there. It was a bit outdated. It hadn’t been touched in a long time, and so we felt like it would be a great tool to leverage for creators. Giving them a better product, something that would be useful with stats and the ability to manage your episodes and all of that. And we figured if we were going to put all this effort into it, that we should probably make it more widely available. And so Jetpack was, I think, the natural fit for us.

[00:06:26] Nathan Wrigley: Yeah, I’m kind of curious how it’s ended up in Jetpack and not just its own plugin. Is it because you’re leveraging the other things that Jetpack can do? Are there sort of dependencies, if you know what I mean, where, okay, it just makes sense because Jetpack already does that piece of the puzzle, and we can just build over the top of that?

Or is it just the brand recognition, the fact that you’ve got an email list that you don’t need to convert and they can just toggle a switch and automatically have got podcasts? What was the reasoning on putting it inside of Jetpack and not just its own thing?

[00:06:54] Tony: I would say, at least from an engineering perspective, there’s stuff that’s in it that is exclusively within Jetpack. So, the ability to do stats, that’s a hard thing to do when you’re having a self-hosted site, to be able to watch and see what apps are actually touching those download files, and then be able to aggregate them all in one place and then give them back to you in a way that’s easy.

So, at least from an architectural perspective, Jetpack was the easiest because it allows us to leverage some of the endpoints that are already there, and use a lot of those tools.

But then secondly, I think it’s also from an overall product perspective, being able to put it alongside other features like newsletters. Where you can have a newsletter, you can be able to take it into the reader. Have this one episode that now spans across multiple different avenues to be consumed, is I think, also another big benefit in putting it into Jetpack. As opposed to just dropping another, because there’s already a lot of plugins out there, a few big plugins that you can grab for free that do podcasting.

[00:07:56] Nathan Wrigley: I think one of the big bits that I realised early on in my podcasting journey was that you’re not really just trying to create an audio feed. It’s more useful as a podcast if you’ve got this kind of wrap around thing. So like you say, you’ve got a home which is yours, AKA your WordPress website. But also things like the capacity to send out an email if people are interested in subscribing, and they don’t necessarily have a podcast player that they use all the time, but they do want to consume your content.

The fact that they can subscribe to a newsletter, you click publish, that newsletter automatically drops in their inbox. It just makes sense that all the jigsaw pieces that a podcaster needs, it feels like WordPress has had forever.

And there is some part of me which is curious that it’s taken this long to come into the, let’s say, .org side of WordPress. Because all of the different parts, the newsletter, the RSS feed, the blog posting, all of that stuff has been available. It just kind of never got joined up. It strikes me as odd because people have moved over to Patreon, Substack has become this whole thing over the last decade. And really it felt like WordPress had that audience a decade ago.

Maybe it’ll claw it back. I certainly hope it does, but it feels like a lot of people have left the WordPress ecosystem for their podcasting because that stuff wasn’t available. Rob, maybe you want to take that one? It’s not really a question, more of an observation.

[00:09:16] Rob Pugh: Yeah, there’s a lot to unpack there. I agree. I think we were a little late in bringing some of these tools to wordpress.org. But I think we’re seeing the renewed focus across the technology space on ownership.

WordPress has remained the best way to do that. And for us to be able to offer these tools to users. It shows everyone that you can, as you said, own your blog your newsletter, your podcast, together. And it does make sense for us to offer all of these tools in one space.

I like to think of it going back to the origins of WordPress, and we started as blogging, everyone getting your thoughts out there and sharing them. Meeting new people, engaging and creating communities. And podcast is just another medium. We provide that for the written word, so of course we should try and provide that for the spoken word as well. So I do hope that we can show people the benefits, and the ease of having it all together and come back and give us a try.

[00:10:11] Nathan Wrigley: Yeah. I think for me at least anyway, that argument is embedded in my soul. The idea of owning your own content on the web is really important. It’d be interesting to see in the year 2026, 2027 and going forward how much that stuff really matters. I’m just curious, in the age of AI whether people still want to own anything at all. But it’ll be certainly interesting to see.

[00:10:30] Rob Pugh: Sorry, yeah, weigh in on that. I think we’ve seen it over decades and comes in waves. When social media started it was really exciting, and people ran and then saw some of the pitfalls, and they start coming back.

And then recently you mentioned Substack, and I loved Substack when it started. It was a space for some serious dialogue, and a place for writers engage. And then over time, well, we need that VC money, and now it’s basically another social media site. And you realise, oh I don’t really own my data, I just own a Substack, and how valuable is that? And it’s coming back.

And I think AI, it’s becoming even, the cycles are quicker now. AI’s incredible, I use it all the time. I use it to help come up with prototypes for how to best display this podcast product. But, you’ll see quickly that you don’t own anything, and you need to have a home like WordPress. And you retain ownership of your audience, and your data and your posts and your podcasts, and that’s, I think, never going to go away, and AI’s only going to reinforce that for people.

[00:11:23] Nathan Wrigley: Yeah, I think one of the curious things as well is if you want to do anything outside of the normal that the platform will allow, so let’s take the example of Substack. There’s a limited subset of things that it can do. The bedrock of what it does I’m sure is excellent. I confess I’ve never used it, but I’ve seen many people deploy it for their own podcast, so you know, it must work.

But the minute you want to stray outside of those boundaries, and you want to do something a little bit different, I don’t know, you might want to sell some merchandise or something like that. Well just pop WooCommerce on top of your website and you’re off to the races.

Or, I don’t know, you want to have a different flavor in the way it looks at Christmas or something, well you just adapt the theme. And I’m, imagining good luck doing that over on these proprietary platforms. I don’t know if that’s possible, but it certainly would be a lot harder than it would be on the WordPress side I would have thought.

[00:12:08] Rob Pugh: For sure the customisation expanding is all very important, but to me even more important is just that it feels like Substack is just another platform that’s changing the rules on their people midstream, and if you don’t like the direction of. Like tried it before and it was nice to have a non-social media site to have serious writing and reading of other serious authors, and now I’m getting short form reel videos on my homepage, and I didn’t sign up for this.

And if you’re a creator over there, you might be stuck. How do you port your audience over? It’s technically possible, so they say they’re open, but it’s a pain, and people don’t want to leave. And if you’re actually successful, they take 10%, which is great when you’re zero paid subscribers. But, there’s people paying $10,000 a month to Substack.

[00:12:48] Nathan Wrigley: They take 10%?

[00:12:49] Rob Pugh: 10% no matter what, which is great if you’re free, but if you have 100 paid subscribers paying you $10 a month, suddenly it’s insane. Like it’s a terrible deal and people feel stuck. Like WordPress even, wordpress.com, jetpack, if don’t like those rules, we can’t change them too much. You can go to any of the other great podcast hosts, or plugins.

[00:13:09] Nathan Wrigley: Yeah, I guess that’s a curious thing. And then you can embed those on your WordPress website and just carry right on as if nothing had happened. Yeah, that’s a really interesting point.

[00:13:15] Rob Pugh: Exactly.

[00:13:16] Nathan Wrigley: So from what I’ve seen, it looks like a really simple solution to implement. What I mean by that is, as a user of your product, it seems like you’re basically doing a bunch of stuff which as a WordPress user you would be simply doing anyway.

Like, you create a post. I don’t know if there’s a requirement to have a special custom post type for a podcast, or if you can just use regular posts. You go in, drop some audio in, and kind of you’re off to the races. Type some text and what have you.

Is it really as simple as that? Is it simply a case of make a post, drop some audio in? Or is there some stuff that you need to do in advance to prepare your podcast? So I’m leading you up the garden path with that question. Tell us how it works. What do you need to do in order to get started? How much work is involved?

[00:13:59] Tony: Yeah, I think that’s it. There are a few settings that are naturally required for starting a show. So you have your typical art for your show. You’ve got to set your categories and things like that in a setting. But then once that’s all set up, all you do is you create a new post, drop in the audio. We actually have an audio block as well, like a podcast episode block that will pull in a lot of the newer, fancier, podcasting 2.0 markup as well for you to do like chapters and things like that. And then that’s it.

As long as it’s within the category, it’s not a custom post type, it’s just a regular post. And then we are able to differentiate between an episode and just a post by two things. One, is it in the designated category that you set? And two, does it have the audio or video? We also have a few video files that we allow as well, and that’s it.

[00:14:46] Nathan Wrigley: Okay, that’s really neat. So you can use a regular WordPress post, but if you don’t assign it the category, let’s say in this case I’ve named it podcast, let’s go with that. If you don’t assign that category, it’s a regular post. Nothing off that tries to smuggle its way into your RSS feed, which would be attempted to be consumed by a podcast player. It just doesn’t go in there.

The minute I assign the category of podcast, drop in some audio, then it’s in that separate RSS feed. Dear listener, if you’re not familiar with that, basically a podcast is an RSS feed. That is literally what it is. Your podcast player is just consuming a bunch of text, which is an RSS feed, and interpreting that in a certain way with images and the audio and what have you.

And so that’s it. That’s all you have to do. Configure the settings, put a piece of audio in, assign the category, click publish. You’re done.

[00:15:35] Tony: Yep, that’s all. That’s all it is. I think the harder part is trying to come up with the titles and filling out the show notes. And, I have a friend who I got to start a podcast when we were working on this product, and he was using it, giving us feedback. But then, it’s like I looked at his podcast, and it was literally just like episode one, and it just, he’s like, “That’s the hard part, is coming up with all of the other stuff.”

[00:15:53] Nathan Wrigley: But you have Jetpack AI as well, don’t you? So there is an opportunity, I would presume, to lean into that. If you were to write a corpus of text that went alongside the, I don’t know, the audio, it could be a transcript or what have you. Presumably then Jetpack can go sift through all of that, and suggest some sensible titles if you really can’t be bothered to work out a title for the podcast episode. But then again, does it have the capacity to do things like trawl through the audio and transcribe and things like that? Or is that a bit roadmap-y still?

[00:16:20] Tony: Yeah. So that was one of the things that we wanted to work on was the ability to transcribe. And, because we have the privilege of working closely with Pocket Casts, we have, a lot of fancy tools that they have built already for their podcasting platform that we were going to try and leverage for the podcast show.

[00:16:39] Nathan Wrigley: Pocket Casts is an Android, iOS, and, it’s a web player as well. It’s a place where you go download onto your phone or what have you and play them. I have it, I use it every single week, and I’ve noticed that whether a transcript is made or not, Pocket Casts actually makes one.

[00:16:54] Tony: Yep.

[00:16:54] Nathan Wrigley: So if I ship a podcast without a transcript, Pocket Casts magically has a transcript. So I don’t know where that voodoo is happening. But that technology, you can then do double duty on that. You can take the technology they’ve built, use it in the Jetpack side of things, and do the transcription. Okay, that’s neat. Sorry, I interrupted. Apologies.

[00:17:11] Tony: You’re good. Yeah, that’s all of it. That’s, it right there.

[00:17:13] Rob Pugh: I think that’s a great segue into Pocket Casts, which in our opinion is the best app to listen to podcasts. The best platform. And one of the really cool things we were able to do with, because we work closely with Pocket Casts, is when you are distributing your podcast. We pick, just to start, the six biggest ones and hold your hand on submitting to them. But Pocket Casts is actually Automattic. Automattic, you can spell it with one or two Ts. And, if you click the button, it just is uploaded to their network It takes minutes, and it’s, some of the other ones, we hold your hand, but it’s a little annoying, and some of them can take a couple days, like Apple, to approve things. But, Pocket Casts just works. I don’t know if you want to add anything on that magic, Tony.

[00:17:52] Tony: Yeah, it’s very simple. It’s like right off the bat. If you already had an episode recorded, you could start a new website, upload your first episode, set your settings, and be on Pocket Casts, I would say, in less than an hour, honestly.

[00:18:06] Nathan Wrigley: Yeah, because you’ve got that tight integration.

[00:18:08] Tony: Yeah. It doesn’t say anything for the website configurations, which I’m sure would take more time, but at the very least, if you wanted to get your show out there, it’s a pretty instant approval.

[00:18:17] Nathan Wrigley: I think podcast players. If you’ve never run a podcast, there’s this whole dance that you have to do. The first time you ever try to release an episode, and that is to get it set up with the distribution channels that are popular. So I’m thinking of things like Apple Podcasts, and YouTube Music, and Amazon, and the list goes on and on. There’s, dozens of them, some more important than others. I think probably Apple is probably the biggest one, and maybe Spotify and some others come in second and third place.

But you have to do this thing where in some cases you have to go and get an account, and there’s really no way around that. Do you do some of that heavy lifting though? Do you make it easy for people to understand how to do it? When I did it, like 10 years ago for the first, and thankfully, only time I really ever had to do it, it was a case of going out and Googling it and reading things. But do you have that information in the UI to make that journey a little bit easier, reduce hours to minutes perhaps?

[00:19:07] Tony: Yep, we have a button.

[00:19:08] Rob Pugh: So there’s a distribution tab which lists the, all six like you mentioned, Amazon, Spotify, Apple, Pocket Casts, Podcast Index, which covers a whole bunch of minor networks. And I’d love to one day have it be fully automatic like it is with Pocket Casts. But some of them you need actual partnerships with these, Apple or Spotify to make that happen, and we haven’t prioritized putting a business person to go start a relationship and that.

So we will organize them for you and try and give clear instructions in our documentation to how to do it. But there is just a button then when you’re looking and it shows you the status of it, if it’s in or not.

[00:19:42] Nathan Wrigley: Okay. So you click the button, do the necessary thing, and then it will report back to you whether or not that has been successful. It’s a bit of a strange vestige really of the internet from way back when. It feels like in this day and age of everybody using APIs to connect to this, that, and the other thing.

But companies like Apple seem to be very unwilling to let that bit of their system be wide open. You’ve got to sign up for an Apple Creators account. I forget exactly what it’s called, but you log in and then you submit your RSS feed. It really doesn’t take that long, but you still have to do it.

[00:20:12] Rob Pugh: Yeah.

[00:20:13] Nathan Wrigley: And I think they’re doing it because they get to see from the inside out, how popular your podcast is. And I don’t know, maybe they can monetize things from their end. I’m not really sure how that works.

[00:20:23] Rob Pugh: It’s really another example of the closed internet.

[00:20:26] Nathan Wrigley: Yeah.

[00:20:26] Rob Pugh: Which is terrible. Why does Apple and Spotify need to be closed? So I think with having your podcast on WordPress with Jetpack, wordpress.com, and being in Pocket Casts, great. Then you’re, in the more of the open garden which is a better place to be.

And the cool thing with our stats, you can see who’s coming, like how many people are listening to your show on Apple versus Spotify versus Pocket Casts. So you know if you’re not getting any from Spotify, then you don’t even need to be there. Of course though, it helps with findability to be everywhere, so we want to give you that option.

[00:20:56] Nathan Wrigley: Yeah, at the end of the day, it all boils down to an RSS feed, which if it’s on your WordPress website presumably contains your domain name, forward slash, I don’t know, feed forward slash something maybe. So your RSS feed is going to be fairly short, probably very on message.

Does it work that way or does it have some sort of Jetpack or, I don’t know, WordPress.com thing in it? Because when you go to these other platforms, it’s typically platformname.com/randomstringof12characters or something like that, which is very hard to read out in your podcast. But the way you’ve got it built, it sounds like the sort of thing that would trip off the tongue. So you know, wptavern.com/podcast. Put that into your podcast player of choice and you’re done. I’m saying all of that like that’s true, but I don’t know if it is.

[00:21:40] Tony: Yeah, that’s it. Slash feed at the end.

[00:21:43] Nathan Wrigley: Okay.

[00:21:43] Tony: Because it is an RSS feed, yeah.

[00:21:45] Nathan Wrigley: That’s still fairly straightforward. But again, that’s a nice bit of branding, isn’t it? And, I think that’s really good.

Linking it back to the branding. We touched on this a minute ago, but if you haven’t started a podcast before, it may not be entirely obvious that you do want those other things like a newsletter, and like the ability to post to socials, and it feels like you’ve got the complete wraparound solution for that.

Because as your podcast grows, which let’s hope it does, then you will probably wish to have a relationship with your listeners via an email newsletter. You probably will wish to be posting on social media. You probably will wish to do all of these different things. So social posting, newsletter, RSS feed, WordPress as the sort of custodian of all the text and the images and the videos that I put in. Is there any other secret sauce that we’ve missed there? Is there any other sort of unique binding that Jetpack brings that we haven’t mentioned there?

[00:22:37] Rob Pugh: I’ll take it back first to like why we started this, and decided to build this, and I think you’re exactly right. First we found there are lots of WordPress.com and Jetpack users who have podcasts somewhere else. And that’s fine, but they were forced to because we didn’t offer it, and that really makes sense. Why would you need to go somewhere else?

So you say today, our goal in creating it was twofold for the people creating the platform. It should just be as easy as possible. Podcasting and writing is hard enough. You should focus on that. Let us handle all the difficult stuff.

Like you said, you need to, have a newsletter and a podcast and a blog and own all of it, and why can’t you do that with one publish event? And then from the consumer’s side of like consumer of content, some people want to listen to only podcasts, and some people want to read on a blog or, say, the WordPress.com reader. Shout out, go check that out if you haven’t in a while.

And like me, I prefer to actually read stuff in my email inbox, like a old weirdo. It shouldn’t be, you should let people consume however they want to, and it shouldn’t be a lot of extra work for you, the host, the creator, to manage all of these things on different platforms. Just have it be as simple as possible, and that was really our goal. And then, yes, exactly what you said with all the other Jetpack stuff. Social media is a great one. Gosh, you could go on and on. Performance, security, basics.

[00:23:46] Nathan Wrigley: Yeah. And it binds to, you said it just then, and it binds to the one publish event. So when I began my podcasting journey you end up with, like all these Zapier connections and different ways that, I don’t know, a webhook which goes off here and does a particular thing because you want it to be posted to this social network. With this, once you’ve got all of the bits and pieces configured, you click publish.

So you know, you do your audio, you write your text, you do all of that in a draft state, upload the audio. But the moment you click publish, the newsletter goes out, the social media posts go out, and all of that just happens automatically. And you don’t have to think about it. And they’re already there in your website.

It’s not like you have to do much. You just toggle, actually we should talk about that. You have to toggle the Jetpack podcast setting on, and presumably the newsletter setting, and yada yada, all those other things. But once you’ve toggled all those things on and got them set up, every time you click publish, all of those dominoes fall, and everything just happens on autopilot, which is really nice.

What do we need to toggle on? How do we set it up? How expensive is it? Let’s start there.

[00:24:50] Rob Pugh: I’ll talk about the pricing and then Tony can talk about the, the toggles.

[00:24:54] Nathan Wrigley: Excellent. Yeah.

[00:24:55] Rob Pugh: Yeah, we talked a bit about the pricing. I think that Automattic has always had a really generous free tier across its products, and it made sense for us to continue that. So you can today go to WordPress.com and start a blog for free.

It’s going to have some ads on it, but it’s free. You can have your newsletter sent out unlimited sends for free with unlimited subscribers, and unlimited podcasts for free. That’s like, amazing deal. We don’t get enough credit for that, but cool.

But we did build some compelling things to make you hopefully want to upgrade, or as you grow your podcast, you’ll find valuable. I think the stats are really cool. To me, all of the essential stats and none of the unessential stats, which if you’re an advanced podcaster might not be as good as you’re looking for. But, for most novice users, you just want to know the basics.

Anything beyond that starts to feel like Google Analytics, like, I’m lost. So just give me the basic. Are they coming on Apple? Where, how many listeners to which episodes, and where in the world are they coming from? Which refers, like which sites are they coming from? That’s a great starting place for me.

Help with distribution, the episode list, having a clear place for all your podcast episodes, the podcast block, really cool. And on WordPress.com too, we include the audio hosting once you upgrade. It’s not on Jetpack yet, so we’re waiting to see if, because we offer a similar thing for VideoPress, shout out best video hosting for WordPress.

[00:26:09] Nathan Wrigley: Yeah, there’s VideoPress will handle the video side of things. That’s becoming the thing, by the way. I’m sure you know that. But in the podcasting space, I went to The Podcast Show in London, about four months ago or something like that. Everybody’s talking about video.

[00:26:22] Rob Pugh: Yeah.

[00:26:23] Nathan Wrigley: And so that being bound into Jetpack as well is just another string to your bow. I’m just going to segue slightly. I think Pocket Cast does a pretty good job of doing things like HLS video. I could be wrong about that, but I’ve got a feeling it does.

[00:26:35] Rob Pugh: They even hook up with your Apple TV now, so you can watch and listen and yeah.

[00:26:40] Nathan Wrigley: Oh, so this is really clever and completely out of the realms of possibility just a year ago. So you could be listening on your headphones whilst you’re out walking the dog on your podcast player, so you’re only listening to audio. And you come back in, put your Apple TV on, turn on the Pocket Cast player, and it will seamlessly drop you right in the video at the exact moment where you finished the dog walk. It’s so clever and so neat. I love all that stuff.

[00:27:08] Rob Pugh: The future is so cool.

[00:27:09] Nathan Wrigley: Yeah.

[00:27:10] Rob Pugh: I love it.

[00:27:10] Nathan Wrigley: Okay. So Tony, how do we switch it on? Is it genuinely one toggle in the Jetpack settings, or is there a little bit more to be set up?

[00:27:17] Tony: Yeah, more or less. There is one toggle to turn the module on. And then once it’s on, you go to Jetpack and click on the podcast option, and then from there, there should just be one button that is to set up your show.

And all it really requires is you either creating a new category or selecting a category. And this is, as we were talking about before, the category feed that is going to be taken over from there. And then you technically are done. But it’s advised that you fill out all of the other base settings, and we walk you through all of the ones that are required by the podcast show apps, to make sure that you don’t get blocked by Apple or Spotify for not having the necessary settings.

[00:27:57] Nathan Wrigley: If I’ve been a podcaster for a number of years and I’ve got, I don’t know, a back catalog of 100 episodes or something like that. How do we handle that? How do we bring in previous episodes? And is there like an automated way of doing that or do I have to go and refigure 100 brand new pages on my WordPress website?

Is there any heavy lifting done there? Let’s just deal with the audio first, just the RSS feed and the audio. Is it a simple case of dropping the old podcast RSS feed in and you’ll capture all that audio and it’ll be on the Jetpack side of things? Let’s do that first.

[00:28:28] Tony: That’s a great question. I am not super familiar with the Core WordPress importer, but I believe that if there is a valid RSS feed with the normal RSS style tags, like enclosure and things like that, you should be able to import your RSS feed. Depending on how it’s configured on your current host, directly into WordPress. I’m not too sure what that would result in exactly. Especially because there’s a lot of different hosts out there, and it’s not like there’s one standard format for exporting your content. But yeah, that should get you part of the way there.

Then I think in the future, we’re really looking to start targeting some of the major current podcast hosts to be able to configure a migration flow to be able to come from those places to ours, in a more seamless way, albeit whatever sort of export they can give you or, whatnot. But I think that’s still on the horizon.

[00:29:27] Nathan Wrigley: Yeah, it’d be really nice to, let’s say I have 100 episodes and I’ve got, it’s over on whatever, hosting platform X over there, for my podcast audio feed. It’d be nice to be able to just suck in all the descriptions, and all the titles and have them be created as WordPress posts with the category assigned. So that essentially my WordPress site with the click of a button and the wait of an hour has suddenly got 100 posts of the podcast type all ready to go. And then, that’ll sit inside my SEO sitemap and all of that kind of stuff. That would be really interesting to be able to do, I think.

[00:29:58] Rob Pugh: Yeah, I think we will try and have that in the future. We usually do try and make importing, especially from closed platforms, super easy. An example, another Substack. We have an amazing Substack importer. They’re not a big podcaster yet, but they, do have some, and we can look at adding that. But if you have all of your newsletter on Substack, you click a button and we bring over your whole, build you a website, bring over all your posts, all your subscribers, even paid subscribers. We seamlessly transfer it to the Stripe account. Everything we’re building, we’re just trying to make it super easy for people to own your data, go wherever you want. We encourage movement in and out, wherever you want to go, it’s up to you.

[00:30:31] Nathan Wrigley: I suppose that then leads me to this question, which is, and you’ve probably just answered it. You’re not holding people behind some sort of paywall here. If people try Jetpack Podcasts out and they decide, “You know what? I really want to go the other direction. I want to maybe go back to where I was, or just move to a new host,” or what have you. You’re not holding any of that hostage, are you? You can take it and run with it and put it somewhere else?

[00:30:52] Rob Pugh: Yeah. Yeah, absolutely not. Like that’s the, I think, one of the fundamentals of WordPress. You should be able to move within WordPress and out as much as you want. I will say that this is a new feature that me and Tony have built. Just because something doesn’t exist in a super streamlined way, doesn’t mean it’s our intention to lock you in. So please reach out and we’ll happily help you migrate off if that’s your wish.

[00:31:15] Nathan Wrigley: So I’ll just let you know, dear listener, that there’s several URLs which rather than read them, because in many cases they can be quite long. But one of them, which is really easy for me to say, I might as well do that one, is wordpress.com/podcast. That’s probably the easiest one. Oh, and maybe this one as well, jetpack.com/support/jetpack-podcast. There’s several more.

[00:31:38] Rob Pugh: Let me jump in. Let me sorry, Because as of two days ago, we now have jetpack.com/podcast.

[00:31:45] Nathan Wrigley: Oh, okay. That’s way better.

[00:31:46] Rob Pugh: We just relaunched the entire jetpack.com site, which is cool. You should go check it out. Yeah, so.

[00:31:51] Nathan Wrigley: Again though, that, so what was that? Jetpack.com/podcast is kind of the home for all of those bits and pieces.

[00:31:56] Rob Pugh: Yep, exactly.

[00:31:57] Nathan Wrigley: In which case, go there. That’s where you’re going to find all of the bits and pieces and I presume, when things are, adapted and modified.

[00:32:03] Rob Pugh: Yeah, the way to think about it’s still for some people confusing about Jetpack. So if you would like a website, the best WordPress hosting, then go to wordpress.com/podcast, and we’ll host your podcast for you. And if you want to host somewhere else, that’s great. Go host your WordPress site somewhere else, then go to jetpack.com/podcast and we’ll get you all set up as well.

[00:32:23] Nathan Wrigley: In which case, I will say thank you Rob, and thank you, Tony. Thanks so much for chatting to me, both of you.

[00:32:28] Rob Pugh: Yeah. Thank you Nathan.

[00:32:28] Tony: Yep, thank you.

[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, migrating to blocks at an enterprise level and what’s involved in moving from a different CMS into WordPress.

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 K. Adam White, or K. Adam for short.  K. Adam is the principal engineer at Human Made, an enterprise WordPress consultancy. He’s been involved with WordPress for almost 20 years, attending his first WordCamp in Boston back in 2011, and has contributed to WordPress Core and the broader open source ecosystem. Human Made is known for delivering complex projects, think high stakes, no room for mistakes? From global brands moving to WordPress.

This time around,  K. Adam delivered a presentation at WordCamp US focused on a crucial topic for anyone modernising their site, migrating to blocks. Human Made has been all in on the block editor since the Gutenberg plugin days, and the team now specialises in large scale migrations from other content management systems like Sitecore, as well as from other WordPress page builders.

Our conversation focused on the technical and editorial challenges of moving tens, or hundreds, of thousands of posts into the world of blocks and patterns. We talked about the need to combine artisanal care, attention to detail in design, layout, and brand, with industrial scale. The ability to automate, audit and validate mass migrations without losing visual fidelity.

We also discussed the use of patterns as a foundation for development, integrating custom and Core blocks, and leveraging new tools, including AI powered agents and open source plugins like Human Made’s, own rehydrator, to streamline migration workflows.

We also touched upon how clients are onboarded. The process of auditing legacy content. Strategies for training editorial teams on the block editor. And there’s a frank reflection on gaps in WordPress, like granular content permissions.

If you are contemplating a move to the block editor, wrestling with a massive content migration, or curious about what happens when enterprise complexity meets the flexibility of WordPress, 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  K. Adam White.

I am joined on the podcast by K. Adam White. Hello, K. Adam.

[00:03:41] K. Adam White: Hello. It’s good to be here.

[00:03:42] Nathan Wrigley: Yeah. Thank you for joining us. You have an interesting name. Just go on, I know it’s totally off piste, but tell us about your name.

[00:03:49] K. Adam White: Sure. It’s a first initial K, and the middle name Adam that got conjoined in college and I quite like it. So I think in a sphere, and a particular niche in WordPress with so many Adams of so many different colours, then K. Adam is a little bit more me.

[00:04:04] Nathan Wrigley: Yeah, nice. So we’re in the corridor, so forgive any noise that you hear on this podcast episode. We can’t avoid it. We’re in the corridor at  WordCamp US, and you have done, some presentation work this time around. Do you want to just tell us, I mean I presume it’s happened because we’re at the very closing stages of the conference. How did it go?

[00:04:21] K. Adam White: It went, as far as I can tell, quite well. My session was early yesterday, right after the morning keynotes in that early slot where everyone’s coffee has kicked in, and the fatigue of the conference hasn’t quite set in yet.

So I had a great audience and the talk I thing went quite well. I’ve had a number of different conversations off the back of it on various different topics that I covered. So the breadth of those discussions has been really exciting for me.

[00:04:44] Nathan Wrigley: So that is going to be the meat and the bones of what we’re going to talk about today. But first, if you don’t mind, let’s talk a little bit about you and what you do and where you work, just so that we can paint your credentials if you like.

So tell us about your job, how long you’ve been in the WordPress space? Who do you work for? Et cetera.

[00:04:59] K. Adam White: Yeah. My job is principal engineer at Human Made. We’re a WordPress enterprise consultancy, and I have been there nine years. I’ve been in the WordPress community quite a lot longer than that. My first WordCamp was WordCamp Boston 2011, which is a mind boggling 15 years ago now. And before that, I had been using WordPress personally since 2007. So we’re coming up on 20 years of involvement, at least as a user. And then, became a contributor in the early 2010s around 2013, I think my first commit landed.

[00:05:25] Nathan Wrigley: Yeah, nice and Human Made, if you haven’t heard, we’ll put the links into the show notes, anything that K. Adam mentions today, we will put us a link on the WP Tavern podcast episode website, so you can click through to it. But go and check out Human Made, definitely one of the big hitters. I think it’s fair to say in the WordPress space.

[00:05:40] K. Adam White: It’s very kind of you to say so.

[00:05:42] Nathan Wrigley: You did your presentation and it was entitled, Migrating to Blocks. I’m going to intuit from that, that Human Made is all in on the block editor. You’re not using some sort of other proprietary platform. Would that be the case?

[00:05:55] K. Adam White: That would be the case. We were very early adopters of Gutenberg back in its plugin days. We were doing work before it was merged for building out some early block sites, testing out what we could do. Learning how to build and change our theme development processes to move in a more block oriented direction, and then follow that directly into the Full Site Editor world.

And it’s been a great ride. We do work with other page builders and other blocks, platforms and frameworks. We do tend to, as a company, work on projects that have some sort of particular technical complexity that made someone come to us rather than a different agency.

That does mean that we are broadly specialised in WordPress as a platform, including many of those page builders. We’ve worked with Elementor, we’ve worked with Divi, Beaver Builder, but we as a company will always advocate for the block editor and the site editor. And we have our own processes oriented more and more towards delivery with that framework in mind.

I think that the thing that is bringing some of the companies that we help to migrate to WordPress into this ecosystem is the flexibility and the quality of the editorial experience. And personally, my opinion is that Gutenberg does that leaps and bounds better than any of our other page builders that don’t have that native integration into the platform.

[00:07:09] Nathan Wrigley: So if a client comes to you and they are agnostic as to what you are going to build with, your default posture would be we are going to use the block editor.

[00:07:16] K. Adam White: Absolutely default.

[00:07:17] Nathan Wrigley: Okay. And do you have to do any level of persuasion anymore? I’m guessing if we were to rewind the clock, let’s go to 2017, soon after Gutenberg started to become more widely available. I imagine there was quite a bit of explaining to do. Do you still have to do any of that? Or is it a case now that the enterprise people understand what’s going on, and there’s less of a back and forth about whether they should use blocks and patterns and whatever else?

[00:07:41] K. Adam White: If we are building from scratch, we haven’t found there is any reluctance. Particularly if people are coming from a different content management system, particularly a different enterprise content management system. The editor is so compelling, that there’s never any objection to using it. They might ask, should we use this or some other thing I’ve heard of? And we can say, the block editor is built in. We feel that it’s the most robust and future proof platform that you can choose. So we would recommend going that route rather than adding in another plugin, however good they are.

But we do still, nonetheless, have some projects where they are already on a page builder, and they might have invested a lot of training. We might have an entire business school worth of people that are very comfortable with whatever their existing system is, whether that’s Beaver Builder or something else, et cetera, Elementor.

And I think that it’s very important for us to remember what our remit is when we come into a project. That, doesn’t always involve helping them change everything to match what we see as the future. I think that’s a responsibility of the client to understand where they are in conjunction with where the WordPress roadmap is, and make their own decisions about what tools are right for them.

So, for existing projects, we’ll work with what’s right for the clients editorial team, but if we have to make a recommendation, it will always be the block editor.

[00:08:56] Nathan Wrigley: Okay. Yeah, good to know. At place in the market where you are, I’m presuming there’s very little room for error. When you build something, it’s got to work out of the box, on day one. You’ve presumably got stakeholders who’ve got editorial teams, and they’re fairly, we’re, dealing with large corporations that can’t afford for there to be mistakes.

So that kind of leads us to the nature of your presentation, which was called, and again, links will be in the show notes on wptavern.com. Migrating to Blocks with Artisanal Care and Industrial Scale. And I’m actually just going to read the first paragraph because it summarises what we’re going to talk about perfectly. It’s fairly long, but I’ll go through it all.

Whether we’re modernising an old personal blog or migrating hundreds of thousands of existing posts from another CMS. Using WordPress in 2026 means converting our contents to blocks. The convert to blocks button in the editor works well enough for one post. But if we have dozens or hundreds, what can we do to make the process less manual and more powerful? How can we integrate a site’s content directly into full block patterns without losing the columns and structure it had before? And then it goes on to mention, a particular build, I presume, where you were leaving one CMS coming into WordPress.

Just lay out some of the fun, interesting problems that you have to overcome when you’re moving from an entirely different CMS into WordPress, because I guess it’s more complicated than, “Look, there’s a bunch of paragraphs and images. Let’s just drag those over and hope for the best.” Tell us what the problem before you is.

[00:10:22] K. Adam White: That’s a great question. It’s actually remarkable how close you can get to satisfaction with just moving paragraphs and images over and hoping for the best. But there is a big gap in terms of visual fidelity.

The editor in a theme that we’ve built for a client will be configured with patterns and templates and all of the block variations that they need to be able to very quickly sketch out a page. If they are starting from scratch, a client with a fully site editing enabled theme can drop a hero pattern on the page, set in the media they need. Change any font sizes within the pallet of what’s available with their brand guidelines encoded in the theme.json. It’s very easy for them to build out and write content fresh.

But if you have, again, hundreds of thousands of posts, even if you’ve built all those patterns, the heading and paragraph and image only approach doesn’t cut it, because then there would be a tremendously backbreaking amount of work, adding group blocks, adding background colours, et cetera.

That’s usually data that is available in one form or the other in the current system. If we’re migrating without a design change, we will have, whether it’s the layout database in Sitecore or a metadata in a different WordPress block editor that we’re migrating from. Or whatever the equivalent is in our source. We want to preserve the layout of the page and the styling elements. So making sure that headings get the right text treatment, that anything that’s italicised comes over. All of the nuances there, particularly around background colours, images, et cetera. That’s the piece that we’ve been over the past year, looking at how we can improve our process when we’re building a new site, but bringing content over from an old.

Within that context, my talk covered two broad areas. The specific tail end of the talk was about how we can actually use the theme patterns that already exist in the theme directory, and use those to inject particular pieces of source data. So if you have a pattern for a hero element, and you know from your source data what the image URL is supposed to be, what the title is supposed to be. We can use the HTML directly from the pattern file, and do lightweight search replaces within that using either direct PHP string replacements or a tool that we’ve written, that I shared a link to called rehydrator, which is a very early stage experiment, that we’ve got out on GitHub.

And we can use that to put the content into the structure that it’s going to need to have for it to be fully, visually correct. So rather than just reducing and throwing away anything that isn’t a heading or a paragraph, we’re taking the framework from the theme pattern that’s been built. And then we’re writing a migrator that takes data and puts it into that HTML structure, and saves that into the post content. So that when an editor opens up a page, it loads correctly in the editor without block validation errors and it looks right on the front end.

[00:13:15] Nathan Wrigley: Okay. There’s a lot of depth in that, isn’t there? We’ll come back to that in a moment.

I’m curious about process of how you, persuade clients that you are going to be able to carry this work out successfully. So how does that actually work? You obviously look at their existing content, you have a discussion about what the new design is going to look like, and then do you build out some kind of templates or patterns or what have you, so that you can then pull in a proportion of the content, maybe, I don’t know, 10 or a hundred or 5,000 or whatever it may be, pieces of content. Check that that’s all right. Show it to the client. How does that workflow go to build up their confidence that what you are going to do when you finally click the button is actually going to succeed?

[00:13:50] K. Adam White: The way that we’ve been approaching that, I think particularly, over the past six months, I should caveat first that this process has changed so much. Because the tools we have available with AI agents have been evolving in leaps and bounds alongside this particular migration process, which started in January.

So in this case, we started out by building patterns that we could put content for one test post, from the existing site manually. Bringing the contents over, copying and pasting headings, et cetera. And using that to create the patterns that we could show to the client to say, does this look correct? Does this structure mirror what you’re expecting? Is this what you expect an author to have available within the post editor?

And then you know, which pieces belong in the template, which pieces are managed at the site editor level? We’ve done a lot of that ahead of starting the actual migration.

Now that the migration is in progress, any subsequent pieces we’re developing in tandem, we’re saying, okay, we have a press release. That press release, we have audited the incoming data, and we have determined that there are four different layouts for press releases. And this one is used the most and it has these elements. This one is used less, but it has images, et cetera.

And we can build the template for that post type, and at the same time write the migrator for identifying the content nodes, and the source data and bringing that information over into the new patterns.

So we have the patterns that we can show, okay, if you’re building something from scratch, this is what that looks like in the editor. But then at the same time, we can run the migrator over, in most cases, all of the relevant type of data and say, and here is a list of pages to validate.

So what we’ve been doing is bringing that to our stakeholder, and allowing them to do spot checks, so that they can look through and validate that there are all of the required elements on the test pages. Things like, “oh, alright, we don’t have a mapper yet for video embeds. So videos are missing,” and that’s usually going to be an all or nothing thing. We’ve found very few cases where we end up with one or two errors on a specific post basis that aren’t related to support for a complete type of output pattern.

[00:15:55] Nathan Wrigley: Is there a sort of fault tolerance there? So obviously in the case of this particular migration, tens of thousands of posts, I guess there’s never going to be a moment where you can be a hundred percent confident apart from reading the 10,000 posts that you’ve done everything correctly. Is there a, we’ll do 10 to begin with, then we’ll go up to a hundred, then we’ll go up to a thousand.

What, is the sort of tolerance that you present to the client? I’m just imagining that just lurking in post 9,999 is just some weird thing that was allowable in the CMS but never got used before or since, and that piece of content got missed. I don’t know what’s allowable in that scenario. So is there any level of tolerance for fault?

[00:16:32] K. Adam White: The major advance that we’ve made with migrations as a broad structure this year is a much better understanding of those edge cases. And the way that we’ve done that is by leveraging Claude and various other tools to do cross site audits to make sure that we have a full picture of the source data.

So we are able to feed in whatever export files we get from our source site. In this case we’re working from Sitecore, which is an enterprise CMS, which has two database structure. There’s actually a database with a content tree, and then another database that contains layout information. And a page is rendered by switching back and forth between those and assembling the final output.

We were able to get exports of the relevant content from both of those, from the developer of the current site. And we fed those and a whole bunch of documents from the product owner into a ongoing conversation with Claude. And we’re able to use that to build some actually node.js scripts that would take the files we’d gotten from the Sitecore devs, and build a local database in SQLite that each developer on the team was able to run locally. And we can query against that to find those edge cases.

So in a combination of writing our own manual queries, or having a chat conversation prompt for finding individual things, and then it will run a number of queries and report back to us. We’re able to identify very quickly, oh, there’s only one press release that has images, that’s interesting. But there are 17 that have a FAQ accordion.

So that type of auditing has become trivial, and it’s mind boggling how much faster that’s allowed us to move in terms of understanding the data that’s there, and building out a mapping of how we’ll migrate through the different types of content.

We don’t tend to start with only 10 pages in a post type because it’s relatively cheap to run the migrator over a thousand instead of 10. And that gives you a lot more content for both various people on the client team, but then also agentic tools to click through and do a little bit of spot check validation.

What we tend to do is to migrate content type by content type, and we’ll prioritise those based on what we see as the balance between scale and complexity.

[00:18:39] Nathan Wrigley: Do you leverage Core blocks wherever possible, or do you bring bespoke Human Made blocks where that’s necessary? Or can you basically bind everything in this particular build to a Core block?

[00:18:51] K. Adam White: Most of the time we will start with Core blocks and get as far as we can with them. This is a change from how we used to do it. Our early days, we had a lot of rapid iteration in the markup that Core blocks were using. In some cases, there was a lot of evolution in how the controls for them were set up.

[00:19:07] Nathan Wrigley: It was brutal.

[00:19:09] K. Adam White: It was brutal. But that pace of change for the main building blocks of a site has slowed down tremendously, and I think it’s a very stable foundation. So we will be pattern first in our development. We will start by working, doing a lot of in-editor prototyping actually, to build out layouts and patterns for each individual unit of content, each individual sort of component group in the source site. And, it will only be when we run into something like a carousel or a modal that we might reach for a off the shelf, third party option that’s not in Core, or bring our own solution to the table.

[00:19:45] Nathan Wrigley: So do you take, when you said pattern there, is a pattern a sub component of a, let’s say post for want of a better word? Or is it that the pattern is the entire post with bits injected into it? So paragraphs, headings, videos, whatever it may be? Like I said, at the beginning, or are you building up the entire post from various different patterns? Here’s a video pattern and here’s a, I don’t know, a paragraph pattern with a heading? Or a background image or whatever it may be.

[00:20:12] K. Adam White: Patterns tends to be at number of different levels. We might have individual patterns for a particular treatment of headline for example. But we also will have a pattern for a hero section. We’ll have a pattern for a hero section plus the bio below that, that we can use to populate a template in the site editor.

We build patterns at multiple levels of granularity, and we have a leaf to trunk system where we’ll make sure that we have renderings, whether they’re Core blocks with either default styling or one or two block variations, or individual patterns for things where we need to compose one or two blocks together. We’ll make sure that we have all of those leaf node pieces of content, all of our paragraphs, all of our inline images. And then we’ll build patterns for those higher level groups, the full width backgrounds with coloration and a particular headline treatment.

We build out those patterns at all of those different levels because it’s nice to have the granularity when we’re writing our migrators, and patterns can reference each other. So you can have an accordion pattern, which includes two references to an accordion item pattern, and you can have all of those little bits of HTML be discreet PHP files in your WordPress theme. So it makes it very simple to pull up in your editor only the code that you need to edit for a particular unit and know how that’s going to be scoped.

[00:21:26] Nathan Wrigley: This is going to sound like such a peculiar question, but it genuinely, from my point of view, this sounds like really interesting and curious work. It sounds, like there’s a lot to get your teeth into. You’re pushing the boundaries a little bit, but also you’ve got the scope of WordPress, which kind of makes it slightly easier.

I’m basically just making the comment that I think I would enjoy doing the work that you are doing. I don’t know if that, yeah, there really a question there.

[00:21:47] K. Adam White: Unfortunately, we’re doing less and less of that work, and Claude’s doing more and more of it. It’s been actually very efficient because this is such a core central construct in the WordPress block editor. There’s a lot of good documentation about it and agentic tools are quite good at helping to build pattern markup.

So, what we’ve been doing is bringing our human eyes onto that, doing all of our spot checks, making sure that things are kept as simple as possible. Because I think we’re all familiar with how verbose and overly complicated output can be from some tools. But then it is also something that I really wish more people were talking about and doing. Brian Coords earlier today in his talk, mentioned that pattern driven development really he sees as something that more and more of the WordPress community should be trying out. Because there are so many things that we used to build custom blocks for, that just strictly aren’t necessary anymore. And we can get so far by composing what we get from the lego kit of WordPress out of the box.

[00:22:40] Nathan Wrigley: Yeah, I feel like if we went back to 2015 and began Gutenberg again, I feel going patterns first would actually be a nicer approach, certainly a more straightforward approach. I know that there’s, ways to overcome that, but I always drop patterns in, never blocks, and then I’m always interacting with the blocks within the pattern. But it’s patterns first for me all the time. Just because I like the fact that I’m dropping in multiple bits of content that are pre-configured and pre-made and pre, I’ve fiddled with the CSS and made it just how I like it. And I just click the button once and there it is, and I can just rinse and repeat and it’s really straightforward.

[00:23:12] K. Adam White: I would agree, and over the past two to five releases of WordPress, we’ve also had such powerful additional tools added to the pattern toolkit. For example, Partially Synced Patterns. Was a major topic that I shared in my talk. Being able to have a reusable pattern and then make the content editable on a post by post basis makes it very seamless for a non-technical editor to go in, and not have access out of the box to stylistic controls that would make something drift from the brand’s guidelines that they’re trying to follow, but still be able to customise link targets, CTA, text, all of the descriptive and image elements.

[00:23:47] Nathan Wrigley: You are in the weeds of WordPress, and I’m in the weeds of WordPress all the time, but I still feel those tools are widely, not misunderstood, that’s the wrong, just there’s a void. Nobody even knows they’re there. There’s just tonnes of tooling inside the block editor that people simply don’t know about, because the UI and the UX is still a bit funky. You’ve got to go to various different places, and it’s easy to go down the wrong route.

Do you know what I mean? There’s a bunch of tools inside a WordPress that if you only had a few hours with somebody over your shoulder pointing out, “okay, click on that, look at that menu that does this thing.” It’s a shame in a way that’s the case. But I do feel there’s a lot of unexplored potential in every WordPress website that presumably you are leveraging. But I guess just because you’re in the weeds of it.

[00:24:30] K. Adam White: Wherever possible, we have the privilege of having a lot of history with the CMS. Human Made was founded in 2010 and has always had a strong open source posture. We’ve contributed to Core, we’ve put plugins out there in the ecosystem that are used by a number of other agencies. We’ve found the best of what our frenemy competitors use, and been able to adopt those into our own processes.

And the benefits of understanding all of the different types of block that you can use tremendously outweigh any time sink that it takes to learn them. I hope that, from my talk, people will now know that in 7.0, we added PHP only blocks, where you can have the attributes auto registered so that you get, even as a non JavaScript developer, a interface in the editor that someone can open up and go in and change values in the sidebar.

I hope that more people learn about Partially Synced Patterns. I hope more people learn about all of the different types of block that we have available, and find ways to integrate those into their own toolkits. Because playing with the grain of WordPress and using the Block Editor for all it’s worth, are how we untap the most value for our clients.

[00:25:34] Nathan Wrigley: Yeah, there is certainly an awful lot of power, and like I said, I just think some of it gets missed.

How much after you’ve done the migration, how much time do you have to spend with the clients? I have this impression that the Gutenberg editor is pretty straightforward, muscle memory for me essentially. Hours of playing in it. I know where all the bits and pieces are.

But I would also recognise that if I was to show it to somebody who’d never played with WordPress and was coming from, in this case Sitecore, how overwhelming is it? And do you take steps to make it less overwhelming by minimising what’s available in the interface, or just disabling options? What do you do in that regard?

[00:26:08] K. Adam White: No matter how much flexibility our clients want, it’s usually valuable to disable some options. I can’t remember a site we’ve shipped recently for any large website where we left the custom colour picker in, for example. You want to do a better job of limiting what people can use, so that we have confidence that the output, no matter how design savvy or not someone is, is going to be consistent with the rest of the site.

My colleague, Joeleen Kennedy, gave a talk a couple years ago at the first  WordCamp US Showcase Day back in 2024, about work we had done customising the editor for that type of simplicity. And in particular things that we can do around colour palette selection. Ways that we can hide the styling controls for certain blocks through having them embedded in a pattern.

It’s interesting to see that in WordPress recently, if you are editing content that has been marked as having come from a pattern in a post, you can edit all of the text, you can edit all of the images and link targets, but you actually have to hit edit pattern in the sidebar in some cases, depending on how the post is set up, to get into the details within the post that allow all of those other controls to be visible.

That divide took a tiny bit of adjustment for people on our client teams, but the separation has helped them stay focused on the content, and worry less about the overwhelming, combinatorial set of styling possibilities that their blocks have.

[00:27:29] Nathan Wrigley: Do you think that the necessary tools are already built into WordPress to do the kind of work that you are doing? Or is there some missing piece that would make it easier for somebody who doesn’t have the deep pockets that presumably Human Made would require, to do that kind of work. Is the default tooling usually okay to migrate things or have you had to build loads of bespoke tooling?

So in terms of if I was to approach a WordPress website and try to migrate from Sitecore over to WordPress, is this something that you absolutely need a team to do, or would you be able to get some simulation of this with Core WordPress?

[00:28:04] K. Adam White: If you had access to the exports of data from a Sitecore website, and you had a core vanilla WordPress install. And you had a LLM tool of some sort, I think that you could do a lot to get close to what you want. The LLM piece, I think enables this to be done by more people without having to be completely familiar with all of the internal nuances of WordPress. You need to direct it to the architectural pattern that you want, but we have found that it speaks Gutenberg pretty well.

[00:28:32] Nathan Wrigley: What was the name of the tool that you said you’d custom and built?

[00:28:34] K. Adam White: We had built a plugin called rehydrator.

[00:28:36] Nathan Wrigley: Okay, rehydrator, yeah.

[00:28:37] K. Adam White: rehydrator is the tool that we use to take a pattern in the theme and then use that pattern as the template when we’re bringing content over to make sure that we keep all of the styling theme side, and that our migration script doesn’t duplicate the markup specifically.

[00:28:51] Nathan Wrigley: What’s Human Made’s approach to the WordPress project in that regard? You said it was a plugin. Does that mean it’s a wordpress.org repository plugin, or is it one that you have on your own, I don’t know, GitHub repository or whatever it may be.

[00:29:01] K. Adam White: We have some things in the .org repository. In this case, that particular plugin is only on GitHub. A number of ones that we build are only on GitHub, because we’re building them for a very transient in time period of a site.

You don’t need a migration tool to be part of your site long term, it’s not something you’re going to be leaving active, and updating month over month when there is a site running. It’s something that you bring in for the purpose of populating the data. And then you can remove that.

And in that regard, for this particular one, at the moment it’s partly because it’s quite young, and it’s also because we don’t see it as being general purpose. So that plugin specifically is on GitHub and publicly available through Composer, but not on the plugin directory.

In other situations, we’ve gone the opposite direction, and anything that we see as being a ongoing value to a site as it’s running, we do try to move those over as we can.

[00:29:52] Nathan Wrigley: Given that you are on the sort of engineering side of Human Made, I don’t know if this question will land, but we seem to be in this interesting period where there’s a lot of chatter, AI kind of fits into the equation a little bit, but there’s a lot of chatter about the, market share of WordPress and whether or not WordPress as a tool will continue with the same numbers and clout and market share and all of those kind of things.

Do you notice at the enterprise level that there’s been any kind of change in a southerly direction? Maybe there’s been a direct change in a northerly direction. What I’m trying to say is, for the enterprise, does WordPress still maintain that kind of pride place, top of the tree, or are you struggling to find new clients?

[00:30:28] K. Adam White: We’re not struggling to find new clients. We’re lucky that we’re doing quite well on marketing, and we also have had a very powerful year in terms of building relationships with new enterprises, and finding ways to take the technology that we believe in and solve their problems with it.

But I would argue that WordPress has never been the top of the enterprise space. And this actually goes back to your question about what is there that might be missing inside WordPress. The biggest thing that I think someone gets from a more, I’m going to use the term loosely, traditional enterprise CMS, is control.

And WordPress has a security model where the ability to edit and publish a piece of content is usually at the post level. There’s ways to add specific permission checks for metadata. There’s ways that you can restrict what’s accessible and editable with custom interfaces and custom API endpoints. But we tend to have things fall down to the capability checks for user can edit post 1, 2, 3. Yes. No.

And that means that if you have a user profile where your organisation depends on someone being able to come in and touch only the headlines and the SEO metadata, we don’t really have a model for that right now in WordPress.

Whereas something like Sitecore, each individual, almost at the level of every string on the site, whether it’s a set of paragraphs or the label of a button, ends up as a individual node in the content tree. And those can be granted or denied to certain users on a much more granular level. So that to me is a bridge that I still am excited to see what we can do within WordPress to maybe build better interfaces, or better primitives in the editor.

Block locking helps a little bit, but it is an API that’s quite difficult for some teams to wrap their heads around. And it also doesn’t really change the fact that if you can edit the post, and you were able to get the code editor up, then if you’re able to save it, you’re able to save it and doesn’t really go block by block. You’d have to write custom validation or permissions logic in order to be able to reject and update based on the user if they’re editing a block that is next to the one that they were supposed to.

[00:32:32] Nathan Wrigley: So do you have to present to the clients? It’ll be fine. This is what WordPress has. Don’t worry too much about it. If you’ve got this permission, yep, sure. You might be able to overlap and think people could delete things or modify things that perhaps they wouldn’t have to. That’s an educational piece on your side. Go and teach everybody not to mess around with things that they shouldn’t be messing around with.

But you would wish that in WordPress you could assign, say, as you described, this H1, this person can amend it, and this person can access the colour palette for the background image over here, but they can’t access the text. That kind of really granular permission. Whereas block locking just, it seems a bit more of a blunt instrument if you know what I mean. It’s binary. It’s locked or it’s not. You’d like to unlock the capabilities within each block so that certain users can do certain things within the same block.

[00:33:15] K. Adam White: Within blocks, we tend to rely on security through obscurity. We can hide or obfuscate controls behind block locking with content only. We can hide them behind patterns. But if someone’s coming to WordPress, we do make sure that they understand upfront what the nuance of control will be. And we will work with them usually to make things more editable.

Again, I will mention that most of the projects that we get that come from one of these more control-oriented CMSs into WordPress, what they’re seeking is actually more flexibility, not less. So they’re making a decision that they are willing to exchange the stringent control that they get in their existing tool for a process-based change. Maybe they add a review step, or add some sort of workflow plugin, so that we can validate that things look good and have someone sign off on it before it gets published. They would prefer to go that route than to sacrifice the ability for the editors to have the full control, and full pallet of options available to them.

[00:34:13] Nathan Wrigley: Right, so that’s a much more loose approach. Everybody can maybe do more than they ought to do. If we have some editorial guideline where that can’t finally hit the public domain because the publish button is unavailable to you, that’s, okay. We’ll accept that kinda halfway house, if you like. That’s interesting.

[00:34:30] K. Adam White: Each client’s needs are going to be slightly different. We do layer in publication checklists. We have tools to be able to say, this has to be tagged with the primary category before it goes live. We have tools to say, this still has lorum ipsum in it. You can add those in and build workflows, but I tend to like to help clients build processes to support those, rather than trying to take a draconian approach and lock everything down. Because then your work is going to be constantly chasing fine-grained permissions controls when you could be working to use that time making sure that all of the editors know what they can do.

[00:35:04] Nathan Wrigley: I just want to drill into this a bit more. I know this isn’t where we were supposed to go, but I find it really interesting. Would you like those things to ship in Core? obviously they suit you down to the ground, all of those granular permissions, but do you think that belongs in Core?

[00:35:17] K. Adam White: I think that we need more workflow in Core.

[00:35:20] Nathan Wrigley: Okay.

[00:35:20] K. Adam White: I know that there’s a number of different agencies and hosts which each have developed our own workflows solutions. I’ve worked across a number of them on projects that I’ve helped to support.

But the notion that if you have something published and you make an edit out of the box, WordPress will automatically put live any further changes that you make to a published post when you hit save. That is probably the single thing that we most frequently have to build some type of plugin into a site to handle.

Because we need to be able to give people an editorial review step. So that is something that I think we have a number of good tools, but I would love to see a more opinionated default in Core that we can use as a foundation for more complicated post editorial workflow. I think that’s the thing that we most frequently run into. That, and also I guess internationalisation are probably the two things that hopefully will come to the surface of the WordPress roadmap over time.

[00:36:13] Nathan Wrigley: Yeah, I’d really not thought about that. Given Human Made’s sort of credentials and what have you. Do you have a lot of clout? Do you just punch above your weight in conversations about what makes it into Core? Do you get involved in those discussions? I’ve literally no idea how that would happen. Do you communicate to people when a release is coming around. Do you have a voice? Do you make yourself available? What is Human Made’s position in terms of getting things pushed into Core?

[00:36:37] K. Adam White: We participate in the project. I personally have been less involved in Core over the past several years than I would have hoped. I’ve been very much enjoying the detailed, quite close to the ground work that I’m doing on our agency projects. But unfortunately, I have taken a bit of a step back on the open source project.

Some of my colleagues are in a slightly different boat. My colleague, John Blackbourn, our Director of Security for our own hosting product is also the head of the Security Team for WordPress? And has been helping us get the core patches out for the recent set of security releases.

We obviously will advocate in calls for feedback within the Gutenberg project when we feel that there’s a particular direction that we see from our projects. We are able to provide feedback on the UI, and the capabilities of new blocks that are being proposed. But that’s all done through the normal Gutenberg GitHub issue, and WordPress

[00:37:28] Nathan Wrigley: So I think we should probably knock it on the head there. We’ve reached our allocated time. I’ll just point out that these days, it used to be the case that if I was at a WordCamp, you’d really have to wait about six months before the video for the presentation was available. I’m pretty sure it’ll be done already, in all honesty. 24 hours seems to be the time there. So if you were to go to WP Tavern, I will make sure that the link to the video, of K. Adam is there. If not, you can probably go to Google and search Migrating to Blocks, and in parenthesis, with Artisanal Care at Industrial Scale, and you’ll be able to see what it is that K. Adam was talking about.

But really, thank you so much for chatting to me today about all of that.

[00:38:06] K. Adam White: Thank you very much. And I can confirm that the video is already live on YouTube.