So, two other Matts at Cloudflare announced EmDash — the spiritual successor to WordPress that solves plugin security.

(Is it nominative determinism or a simulation glitch that everyone trying to terraform the web has some variation of “Matthew” in their name? I was in a call set up by Matthew Prince, talking to Matt Taylor and Matt Kane, with my right hand there, Matías.)

First, I’m going to tell you why this isn’t spiritually tied to WordPress at all, then why they haven’t solved plugin security, and finally offer some suggestions.

The Spirit of WordPress

WordPress exists to democratize publishing. That means we put it everywhere. You can run WordPress on a Raspberry Pi, on your phone, on your desktop, on a random web host in Indonesia charging 99 cents a month, and you can run it scaled up on AWS or across multiple datacenters.

The same code. When you download WordPress Playground you’re running the same code that’s being attacked a thousand times a second at WhiteHouse.gov. That’s what we mean when we say democratization.

It’s all built on open source and web standards. You can run it anywhere; there’s no lock-in.

That’s why we do what we do. It’s really hard. You can come after our users, but please don’t claim to be our spiritual successor without understanding our spirit.

The Spirit of EmDash

I think EmDash was created to sell more Cloudflare services. And that’s okay! It can kinda run on Netlify or Vercel, but good stuff works best on Cloudflare. This is where I’m going to stop and say, I really like Cloudflare! I think they’re one of the top engineering organizations on the planet; they run incredible infrastructure, and their public stock is one of the few I own. And I love that this is open source! That’s more important than anything. I will never belittle a fellow open source CMS; I only hate the proprietary ones.

If you want to adopt a CMS that will work seamlessly with Cloudflare and make it hard for you to ever switch vendors, EmDash is an incredible choice.

Claimed Plugin Security

In another example of them not understanding the spirit of WordPress, the fact that plugins can change every aspect of your WordPress experience is a feature, not a bug! And their sandboxing breaks down as soon as you look at what most WordPress plugins do.

I know we get a bad rep because there are 62k plugins with wildly variable engineering quality, and more every day, and when one installed on 0.01% of our user base has a vulnerability, a bunch of websites write breathless articles that get clicks saying “122,000 WordPress Sites Vulnerable!”

That, by the way, I think we’ll be able to fix in the next 18 months with AI. The plugin security only works on Cloudflare.

Critical Feedback

As I said, we had a call with Cloudflare on March 23rd, where they asked for feedback on this thing they built but didn’t tell us the name, said it would probably launch in their developer week towards the end of April, and some top colleagues and I offered to help. I wish I could say the things I’m saying in this blog post on that call, and if they had just shared the announcement post I could have, but in the spirit of open source here’s what I would have said:

1. If they had said the name I would have asked if they had any other options because I have an amazing colleague named Emdash who is doing some of the most exciting stuff with WordPress and AI. (BTW I think our Em will have more impact on the web than this in five years.)
2. I actually think the product is very solid, there’s some excellent engineering, migration tools, it’s very fast, and the Astro integration is nice.
3. I’d be surprised if this doesn’t get tens of thousands of sites on it.
4. The UI is in the uncanny valley of being sorta-WordPress sorta-not. I know it wasn’t a weekend vibecode project, but it has some of that smell. Stuff breaks at the edges.
5. I think using TinyMCE is a regression, and they should adopt Gutenberg, which we licensed and created to be used by other CMSes. (Correction: They use Portable Text not TinyMCE, but same UI criticism applies.)
6. The Skills are amazing, a brilliant strategy, and we need to do the same as soon as possible. I’ve been working on something similar and got some good ideas from their implementation.
7. I’m not going to say which parts, but they copied a lot of things we’re planning to kill. Build from first principles. Make it better. Skate to where the puck is going.

There’s a new CMS every other day. And that’s great! I love building CMSes and I totally get why other people do, too.

In Conclusion

Some day, there may be a spiritual successor to WordPress that is even more open. When that happens, I hope we learn from it and grow together. [removed “out of your mouth” sentence, too spicy for Western palates.] I’ve mostly focused on this post on just the software, but WordPress is also so much about the community — the meetups, the WordCamps, the art, the college programs, the tattoos, the books… The closest thing I’ve seen to a spiritual successor isn’t another CMS, it’s been OpenClaw.

Thanks to colleague Batuhan İçöz for helping review this.

I’m really excited to introduce a project I worked on with various AI agents the other night, which I think represents a new way we might build things in the future.

First, the problem: My WordPress site has 5,600+ posts going back decades, and I had some categories that were old and I didn’t really use anymore, and I wasn’t happy with the structure. Every time I made a new post, it irked me a little, and I had this long-standing itch to go back and clean up all my categories, but I knew it was going to be a slog.

Let me present Taxonomist, a new open-source tool you can run with one copy-and-paste command line that solves this problem. Here’s the idea:

1. You run this code in your terminal, and it spins up a Claude Code instance that asks you for your URL.
2. Then it takes that and figures out what type of site you have, which APIs are available, and starts downloading all your posts locally for analysis.
3. Sub-agents analyze every post against your current categories and thinks about suggesting new ones.
4. It previews all the changes.
5. Tries a variety of ways to authenticate against your site and make all the changes.
6. Logs everything locally, so anything is reversible later.

THIS IS VERY ALPHA. PROBABLY BUGGY. BE CAREFUL WITH IT. PATCHES WELCOME. MAYBE MAKE A BACKUP OF YOUR SITE BEFORE YOU CHANGE IT.

It kind of just worked. I ran it live against ma.tt and it cleaned up a ton of stuff pretty much exactly how I wanted. But there’s a lot of weird stuff happening here, so I don’t know quite what this is yet.

1. It’s very non-deterministic! There is some pre-written code, and probably could be more, but a lot of the code is generated on the fly by your agent. This creates interesting bugs where people testing with less powerful models had some odd behavior.
2. I kind of want a directory of these useful AI agents on WordPress.org, but also, there’s something a little strange about trusting a remote shell script to run on your machine.
3. I tested this with Claude, but there’s no reason Codex couldn’t use the repo in the exact same way, and I’d love to improve the quick start script to start by detecting all the agents you have, asking which you’d like to use, and also which directory you’d like to work in. I think we could kill the cd taxonomist-main && claude "start" part of it.
4. Because much of the code and commands are generated on the fly from prompts, it’s very resilient! I’ve seen people try it, and it ran into errors with libraries or whatever, but it just figured out how to work around them.
5. I’d love it if, at the end of every session, there was a moment for self-reflection where the agent would take the repository and suggest upstream issues and PRs based on anything that went wrong. Then this could recursively self-improve very quickly.
6. There are some obvious improvements to this, for example, doing this for tags. Sometimes it creates too many categories when you might only want 3-5 for your theme.
7. One fun thing is a bunch of the work of this just uses public WordPress APIs, so you can run it against any site! I like using distributed.blog as a demo. It’ll still do all the fun downloading and analysis and everything, you just won’t be able to make changes.
8. I now have a local cache of all my WordPress posts I can do other interesting things with, and that’s cool.
9. The logging and reverting probably still has some bugs in it.
10. You can riff with it along the way, so for example, it suggested I get rid of my Audrey category because it didn’t have enough posts, and I asked it to look at all the companies on Audrey.co website and categorize any posts that talk about them as Audrey, which created like 50 more.
11. I want to check the GitHub repo for any updates before it starts, and maybe periodically, because it’s iterating and improving really fast.
12. It’s not the default but the entire thing is way more pleasant if you run it with skip-permissions. So testing I usually run the one-liner, exit, resume with skip.
13. You can see some of my prompt history in the Github but I apologize it’s not comprehensive, I also used Gemini and Codex with this and got lots of value from them.

So, not sure what this is, but please check it out, play with it, submit improvements or ideas, and think about what’s next. Might host a Zoom or something to brainstorm.

The final thing I say is that this was a very different process of writing software for me. Instead of staying at the computer the entire time, I found myself going away for a bit, napping and dreaming about the code, coming back with new ideas and riffing on them. Maybe I’ll return to my Uberman polyphasic sleep days? Nap-driven development?

BTW I have lots of thoughts and feedback for Emdash but I thought this was more interesting, will try to get that out later tonight. One preview: TinyMCE is a regression; they should use Gutenberg! We designed it for other CMSes and would be fun to have some common ground to jam on.