WordPress 7.0: What Developers Need to Know Before May 20

WordPress 7.0 lands in five days — May 20. It is the biggest core release in years: a native AI layer, three new developer APIs, a stricter editor architecture, and a PHP floor that quietly orphans anyone still on 7.2 or 7.3. If you build or maintain plugins, themes, or custom blocks, this is not the release you can afford to skim.

Your Custom Blocks May Break — And 7.0 Is the Window to Fix It

The most urgent issue in this release is not a feature. It is the iframed post editor. Starting with 7.0, the editor activates iframe mode whenever all inserted blocks use Block API version 3+. Any block that reaches outside its iframe context — accessing the global window or document — will break. Silently. In production, after someone hits “Update WordPress.”

Full enforcement is deferred to 7.1, but treat that as a soft deadline, not a reprieve. The 7.0 release cycle is explicitly framed as the compatibility window. Agency developers maintaining bespoke client code are the highest-risk group here, especially those who don’t closely follow the Make WordPress Core blog. If that is you, test against RC4 today using the official iframed editor migration guide. Third-party libraries that make global DOM assumptions are equally suspect — audit your dependencies.

WordPress Now Has a Native AI Layer

The architecturally significant addition in 7.0 is WP_AI_Client: a provider-agnostic PHP API that lets plugins send prompts to AI models through a consistent interface. Site administrators configure providers through a new Settings > Connectors screen. Three official connectors ship out of the box — OpenAI, Anthropic, and Google.

The entry point is wp_ai_client_prompt(), which returns a fluent builder:

$text = wp_ai_client_prompt('Summarize the benefits of caching in WordPress.')
    ->using_temperature(0.7)
    ->using_max_tokens(500)
    ->generate_text();

if (is_wp_error($text)) {
    // Handle error per WordPress conventions
}

The API handles text, images, TTS, video, and multimodal output. Before rendering any AI-powered UI, use feature detection: is_supported_for_text_generation() runs locally without making an API call, so there is no reason to skip it. A JavaScript counterpart is available via the wp-ai-client package, though the official recommendation is to implement per-feature REST API endpoints rather than call the JS API directly from client-side code.

Why does this matter beyond the API itself? WordPress powers roughly 43% of the web. A standardized AI interface built into core means AI-powered plugins can now reach that entire install base without shipping custom connectors, managing API keys, or asking site owners to configure five different settings panels. That is a platform play, and if you are building a WordPress AI plugin today, the calculus for rolling your own connector just changed. The WP AI Client announcement has the full migration path from the old AI_Client::prompt() pattern.

PHP 7.2 and 7.3 Support Is Gone

WordPress 7.0 drops PHP 7.2 and 7.3. The new floor is PHP 7.4 — but it is worth noting that PHP 7.4 itself reached end-of-life in November 2022. The floor shifted, but the recommended target is PHP 8.2 or 8.3, especially for WP AI Client performance. Sites on PHP 7.2 or 7.3 will not receive the 7.0 update automatically, which is the only thing that prevents this from being a larger incident.

If you are advising clients or maintaining hosted WordPress stacks, update your minimum recommendation today. PHP 8.2 is the honest floor for a site you want to be running in 2026.

PHP-Only Blocks: React Was Never Mandatory

One of the more satisfying additions in 7.0 is PHP-only block registration. Previously, even a simple server-rendered block required a webpack pipeline, a React component, block.json, and a JavaScript build step. Now you can skip all of that. Declare 'supports' => array('autoRegister' => true) in your render callback, and WordPress generates the inspector controls automatically from your attribute types.

This is not a replacement for complex interactive blocks — those still need JavaScript. But for server-rendered content blocks, data-display components, and anything that does not require client-side interactivity, this removes a real barrier to entry. The Block Bindings API also expands in 7.0: pattern overrides now work with any custom block, not just core blocks, through the block_bindings_supported_attributes filter.

Real-Time Collaboration Did Not Ship

The headline absence in 7.0 is Real-Time Collaboration (RTC), which was originally the flagship feature of the release. It was cut during RC development after fuzz testing surfaced recurring bugs around race conditions, server load, and memory efficiency. RTC remains a stated priority for a future release. The team is taking the right call here — shipping broken collaborative editing would have been a significantly worse outcome.

What did ship in its place is arguably more durable: the AI Client, DataViews framework improvements, and the PHP-only block infrastructure that will support future features. These are platform primitives, not user-facing demos.

What to Do Before May 20

• Test your custom blocks against RC4 — check for global window/document access that will break in the iframe context
• Verify your server PHP version — 8.2+ is the target, 7.4 is the minimum
• Audit plugins that implement AI connectors — migrate to wp_ai_client_prompt() and set minimum WordPress requirement to 7.0
• Review the official WordPress 7.0 Field Guide and the May 2026 developer roundup for the full list of changes
• Check if any of your patterns use nested blocks — they may now require "role": "content" in block.json due to the new contentOnly default

Five days is enough time to find the problems before they find your clients.