WordPress 7.0 Beta 1 is close, and if you skipped the Gutenberg 22.4 and 22.5 releases some of it will surprise you. The pattern repeats every cycle: features get merged in a rush before the deadline, then the “why is my block UI broken” tickets start arriving. This round leans harder on architecture than most.
Fourteen years of core updates have taught me that a maintenance release like WordPress 6.9.1 is usually the quiet stretch before something bigger. The WordPress 7.0 features below are the ones that change how you work.
The always-iframed editor
The block editor has run a hybrid setup for years. One block on an older API version and WordPress dropped the iframe, rendering everything in the main document, which made style isolation unreliable. In WordPress 7.0 the post editor is always iframed.
That helps CSS consistency and it breaks legacy editor JavaScript. Any script that reaches for the global document or window to find elements comes up empty, because the block now sits inside its own document. Switch those lookups to ownerDocument and defaultView. The official migration guide has the details.
// The senior dev way to handle the iframe shift
const ref = useRefEffect( ( element ) => {
const { ownerDocument } = element;
const { defaultView } = ownerDocument;
// Instead of jQuery(document), use:
// jQuery(ownerDocument).find('.my-selector');
} );Viewport-based visibility goes native
Viewport-based block visibility is one of the most requested WordPress 7.0 features, and it is landing. We have all been writing hide-on-mobile CSS classes for a decade. Gutenberg is moving that into the core metadata structure instead.
Several pull requests are still refactoring how this behaves. Rather than toggling a class, the editor takes over the conditional rendering, which can shrink the DOM on mobile. Watch how hidden blocks look inside the editor, though. A block that exists but is invisible at your current viewport is easy to lose track of.
Per-instance custom CSS
Gutenberg 22.5 added an Additional CSS field on individual block instances. It applies a .has-custom-css class and injects the styles directly. I have mixed feelings about it. For the one-off client request that does not justify a whole block style variation it is exactly right, and six months later nobody remembers which block is carrying the override.
If it becomes your default on every site, something further upstream is wrong. Put what you can into theme.json as global styles. I wrote about Gutenberg 22.4 pattern overrides, which handle variations without stuffing raw CSS strings into the database.
Studio CLI and AI experiments
WordPress Studio 1.7.0 shipped, and the CLI updates are worth your attention. You can drive almost the whole local environment from the terminal now. That is aimed squarely at anyone running AI agents like Cursor or Claude Code: once the environment setup is scriptable, the agent can turn out the boilerplate far faster.
The AI Experiments plugin is also moving closer to the core experience, with backend API support for generating excerpts and images. It is still experimental, and it is the clearest look you get right now at where agentic WordPress is going.
If this release cycle is eating your dev hours, I take that work on. I have been wrestling with WordPress since the 4.x days.
What to do before beta 1
Consistency and isolation are the through line here. Iframe enforcement ends the loose approach to editor styling that plenty of blocks still depend on. Move your blocks to API version 3, try the viewport controls in Playground, and set expectations with clients about the per-block CSS field before they find it on their own. Otherwise you are the one fixing it at 2 AM.
