WordPress 7.0 Beta 1 is looming on the horizon, and if you haven’t been tracking the Gutenberg 22.4 and 22.5 releases, you’re in for a few surprises. We’ve seen this pattern before: a mad dash to merge features before the deadline, followed by the inevitable “why is my block UI broken?” tickets. This February update is particularly heavy on architectural shifts that will define how we build for the next few years.
I’ve spent the last 14 years wrestling with core updates, and if there’s one thing I’ve learned, it’s that “maintenance releases” like WordPress 6.9.1 are just the calm before the storm. Let’s look at the WordPress 7.0 features that actually matter to your workflow.
The Always-Iframed Editor: No More Escape Hatches
For years, the block editor used a hybrid approach. If you had a block using an older API version, WordPress would drop the iframe and render everything in the main document. It was a mess for style isolation. In WordPress 7.0, the post editor will always be iframed, period.
This is a massive win for CSS consistency, but it’s a potential breaking change for any legacy JavaScript you’ve got running in the editor. If your scripts rely on the global document or window to find elements, they’re going to fail because your block is now living in its own little world. You need to start using ownerDocument and defaultView. Check the official migration guide to save yourself a headache.
// 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: Native Responsiveness
One of the most requested WordPress 7.0 features is finally landing: viewport-based block visibility. We’ve all been using “hide-on-mobile” CSS classes for a decade. Now, Gutenberg is baking this into the core metadata structure.
There are several active pull requests refactoring how this works. Instead of just toggling a class, the block editor will handle the conditional rendering logic. This is great for performance because it potentially reduces the DOM size on mobile, but keep an eye on how it handles “hidden” blocks in the editor. You don’t want to lose track of blocks that are technically present but invisible in your current view.
Per-Instance Custom CSS: A Tool and a Trap
Gutenberg 22.5 introduced a new “Additional CSS” field for individual block instances. It adds a .has-custom-css class and injects the styles directly. Honestly, this feels like a double-edged sword. It’s perfect for that one-off client request that doesn’t justify a new block style variation, but it’s a nightmare for long-term maintenance.
If you find yourself using this on every site, you’re doing it wrong. Keep your architectural integrity. Use global styles in theme.json whenever possible. I recently wrote about Gutenberg 22.4 pattern overrides, which is a much cleaner way to handle variations without bloating the database with raw CSS strings.
Developer Productivity: Studio CLI and AI Experiments
WordPress Studio version 1.7.0 just dropped, and the CLI updates are legitimate. You can now drive almost the entire local environment via terminal. This is specifically designed for those of us using AI agents like Cursor or Claude Code. If you can script the environment setup, the AI can build the boilerplate for you significantly faster.
Speaking of AI, the AI Experiments plugin is getting integrated deeper into the core experience. We’re seeing backend API support for automated excerpt generation and image generation. It’s experimental, sure, but the foundation for agentic WordPress sites is being laid right now.
Look, if this WordPress 7.0 features stuff is eating up your dev hours, let me handle it. I’ve been wrestling with WordPress since the 4.x days.
The February Takeaway
The theme for 2026 is consistency and isolation. The iframe enforcement is a clear signal: the “Wild West” of editor styling is over. Update your blocks to API version 3, start experimenting with the new viewport controls in Playground, and for the love of performance, don’t let your clients go crazy with the per-block custom CSS field. Ship clean code, or you’ll be the one fixing it at 2 AM.
