WordPress 7.0 was supposed to launch yesterday at WordCamp Asia. It didn't. On March 31st, the core team announced a delay to sort out the data storage behind real-time collaboration. A new schedule should land by April 22nd.

If you've been following the coverage, you'd think this release is primarily about AI. Every WordPress agency with a blog has published their version of "WordPress 7.0: The AI Era Begins." Having spent time with the betas and the developer notes, the AI stuff is comfortably the least interesting thing in this release, and the engineering effort going into it raises some questions about where the project's priorities are heading.

The delay

The real-time collaboration feature lets multiple users edit the same post simultaneously. The delay happened because the sync data storage was causing cache invalidation problems, and the team decided to fix it properly rather than ship it broken for the conference stage.

Good. After three security releases in 24 hours back in March (6.9.2 introduced a white-screen bug, 6.9.3 patched that the same evening, 6.9.4 dropped the next day when they found some fixes hadn't fully applied), taking extra time to get a flagship feature right is the correct call.

For sites where multiple editors touch content, collaborative editing could be a genuine workflow improvement. It uses HTTP polling that works on any standard hosting, no WebSocket requirement. If it ships reliably, it's probably the most significant feature in the release.

The catch: it only works in the block editor. Classic meta boxes don't sync, and the collaboration feature actually disables itself when it detects them.

That's a bigger limitation than the coverage suggests. Gutenberg is great for content-heavy editorial sites where the output is essentially pages of blocks. But a huge number of production WordPress sites use meta boxes for good reason. The moment you need structured data entry, repeatable field groups, complex post relationships, or anything that resembles application data rather than page content, meta boxes and tools like ACF are still the right interface. The block editor wasn't designed for that kind of work, and shoehorning structured data into blocks creates a worse experience for the people entering it.

So the "Google Docs for WordPress" pitch comes with a fairly significant asterisk: it's Google Docs for the subset of WordPress sites that have fully committed to the block editor for everything. That's a lot of sites, but it's not all of them, and pretending otherwise does a disservice to the developers who'll have to explain the limitation to their clients.

The AI stuff

WordPress 7.0 introduces a centralised AI infrastructure layer. New Connectors screen in settings. Enter your API key for OpenAI, Anthropic, or Google once, every plugin on the site can use it. Provider-agnostic. Opt-in. Graceful degradation if you don't configure anything.

The architecture is sensible. If AI features are going to exist in the WordPress ecosystem, and they already do through dozens of plugins, having shared credential management is better than every plugin rolling its own. No argument there.

But there's a priorities question worth asking.

WordPress has had basic custom fields forever, but they're key-value pairs and not much else. ACF became one of the most essential plugins in the ecosystem because it provided what core never did: repeater fields, flexible content layouts, relationship fields, options pages, proper field group management. The kind of structured content tools that nearly every non-trivial site needs. After twenty-odd years, the answer to "how do I build structured content in WordPress" is still "install a third-party plugin."

Multilingual support is in the same boat. Still plugin-dependent, tentatively pencilled in for 7.2 at the earliest. Proper content modelling, same story. And while we're at it, WordPress still doesn't have a proper notifications manager. Admin notices remain a chaotic stack of coloured divs that every plugin dumps at the top of the dashboard with no centralised way to manage, dismiss, or prioritise them. It's the kind of basic housekeeping that would take a fraction of the effort being poured into AI infrastructure.

These are foundational CMS features that developers have been requesting for years. Seeing significant engineering resources go into AI Connectors and an AI Client API while those gaps persist raises the question of whether the project is chasing attention rather than solving its most pressing problems. AI infrastructure is a reasonable thing to build eventually. It's a strange thing to prioritise over structured content.

The features worth paying attention to

I've never been Gutenberg's biggest fan. For content-heavy editorial sites it's fine, but for the kind of builds I do, sites with structured data, custom post types, and specific client workflows, the block editor has always felt like it was designed for a different kind of WordPress than the one I work in. That said, 7.0 has some improvements that suggest it's slowly moving in a more practical direction.

Visual revision tracking. Colour-coded overlays in the revisions panel. Green for added blocks, red for removed, yellow for modified. For text, additions are underlined, deletions shown in strikethrough. Years overdue. For sites with content teams doing editorial review, this is immediately useful.

ContentOnly pattern editing. Patterns default to a clean, focused mode where users see fields instead of the full block editor interface. This directly addresses one of the most common complaints about handing WordPress to non-technical clients. Detach the pattern if you need structural access. This is the kind of thinking Gutenberg has needed more of from the start: making the editing experience simpler for the people who actually use it every day rather than more powerful for demo videos.

Pseudo-element support in theme.json. Style :hover, :focus, and :active states directly in theme.json without writing custom CSS. Small change, constant friction removed in theme development.

Navigation overlays. Mobile menu overlays are out of experimental, with a guided setup flow. Anyone who's fought with mobile navigation in WordPress themes knows why this matters.

None of these are going to convert a Gutenberg sceptic overnight, and they don't do much for developers building anything beyond straightforward content sites. But they're steps in the right direction, and they're the substance of this release.

There's also PHP-only block registration, which lets you register a block without writing any JavaScript. On the surface that sounds useful, but ACF solved this problem years ago when the block editor first launched, and did it better, with support for interactive previews and field integration. The core implementation still doesn't match that. It's a pattern that keeps repeating: the WordPress project eventually gets around to building something the plugin ecosystem figured out ages ago, ships a less capable version, and calls it a feature. It's hard not to see it as another example of engineering effort going to the wrong places.

The competitive landscape is noisier than it is threatening

The same week WordPress announced its delay, Cloudflare launched EmDash, a TypeScript CMS it's calling "the spiritual successor to WordPress." Built in two months with AI agents, runs on Cloudflare Workers.

EmDash has some interesting ideas around plugin sandboxing and security. But from what I can tell, its headline feature, isolated plugin execution, appears to only work properly on Cloudflare's own infrastructure. You can apparently run it on any Node.js server, but without Workers you seem to lose the security model that's supposed to be the whole point. It's MIT-licensed, which is great, but if the key selling points only work within one vendor's ecosystem, that feels more like a product designed to grow Cloudflare's platform than a genuine open source alternative. I haven't built anything with it yet so I'm happy to be corrected, but the "spiritual successor to WordPress" framing feels like a stretch from what I've seen so far.

Meanwhile, every platform from Wix to Hostinger is marketing their AI site builders as though they can produce a professional website from a few sentences. They can't. What they produce is a template with AI-generated filler text and stock imagery that looks passable in a demo video and falls apart the moment a real business tries to use it. If you've ever had to unpick one of these for a client who outgrew it in three months, you know exactly how much time these tools save.

WordPress's competitive advantage isn't AI features. It's the twenty-year ecosystem, the hosting flexibility, and the genuine ownership of content and infrastructure. That's worth protecting and improving. The way to protect it is to make WordPress excellent at the fundamentals, not to chase whatever the rest of the industry is shouting about this quarter.

If you're trying to apply that thinking to a real-world build, migration or overhaul, I also offer freelance WordPress development for custom sites, structured content setups and long-term support.