«WordPress 7.0 — it’s like a major renovation in your apartment. The result can be wonderful, but the process is nerve-wracking»
WordPress 7.0: cosmetic repairs or a real upgrade?
On February 20, the WordPress community received great news about 7.0 Beta 1 update, and then — Beta 2 (February 26). After which I immediately installed the beta version, clicked around, tinkered with it — and I have quite mixed impressions. Some things really please and surprise me, some are downright annoying, and some will require months of real use with clients before I can confidently say anything concrete.
The official release is scheduled for April 9, 2026, and there’s plenty of time for testing. But already now you can see the direction WordPress is moving. And this direction is not for everyone.
What the community is saying
The mood in the community is mixed. In threads and comments, you can find the same thought repeated: the global direction of WordPress is not liked, the platform is accumulating features that no one asked for. But as long as it stably closes client tasks — everyone keeps using it. Business needs results, not arguments about the perfect platform.
Some praise it, some hate it, some just work, ignoring the long-familiar shortcomings of the platform — a typical picture for every major release. Among the comments, you can find interesting thoughts: customers come with a desire to quickly build an MVP on WordPress because it’s fast and cheap. Like, once it starts making money, we’ll switch to something else. But in reality, these projects then live for years and make good money and nobody switches anywhere, staying on WordPress.
This is a reality often ignored in technical discussions. WordPress lives not because it’s perfect. It lives because it closes tasks. And 7.0 is an attempt to make it close even more tasks, the only question is — at what cost?
Admin panel: new colors, smooth transitions and eye strain
Let me start with what doesn’t satisfy me so far. WordPress 7.0 changes the appearance of the admin panel. New color scheme and smooth transitions between pages without reloading.
Sounds good on paper. In practice — the colors are jarring. I’m serious. The community writes about it directly: white screen on transitions between pages, colors — they hurt the eyes. Developers who set custom admin themes for clients sighed with relief. The rest — not so much.
Smooth transitions between admin pages — this is something no one asked for. WordPress admin is a working tool. I don’t need animation when switching from “Posts” to “Pages”. I need it to work quickly and predictably. These view transitions are like putting neon undercarriage lighting on a work van. Pretty? Maybe. Necessary? No.
It’s good that custom admin themes still work. For client projects I always install a branded admin theme, so this problem will affect me minimally. But for those working with the default interface — this will be quite a surprise.
Gutenberg in iframe — finally
Now this is really good news. In WordPress 6.9, they started moving the editor to an isolated iframe, but only for blocks with apiVersion 3. In 7.0, this transition is complete.
Why is this important? Because until now, styles from the theme, plugins, and the admin itself were mixed in the editor into one chaos. CSS conflicts between the theme and Gutenberg — this is a classic for every WordPress developer. The iframe isolates the editor from the rest of the admin. Clean sandbox with no CSS conflicts. For custom WordPress development, this means less time debugging style issues and more predictability. Something that should have been done two years ago, but better late than never.
Collaborative editing: Google Docs for WordPress?
WordPress 7.0 introduces real-time collaborative editing mode. Multiple people can work on the same post at the same time, see each other’s cursors, and leave comments via Notes. Synchronization happens through HTTP-polling with the option of WebSocket.
The community already jokes: «Probably so the client can break the layout in real time and interfere with the developer». And you know what — that’s true, that’s how it will be in the future.
Honestly, I don’t know how useful this will be on real projects. Notes since version 6.9 have already found an authorization bypass vulnerability, which was patched in 6.9.4. Collaboration sounds like a feature for large editorial teams with dozens of authors. For a typical WordPress site with one or two content managers — this is powerful overkill.
But I’m not dismissing it completely. Need to test on real projects with real clients, see how it behaves under load, with slow internet, with conflicting edits. For now — interesting, but without euphoria.
AI in the core: Settings → Connectors
WordPress 7.0 adds a new Settings → Connectors page to connect external AI providers. OpenAI, Claude, Gemini — all through a single interface. Plus WP AI Client — a unified API for working with any provider from plugins and themes.
Someone from the community wrote: «Everyone’s trying to jump on this “We need AI, doesn’t matter why” wagon. Hear I’ll have to cut it out so the site is more stable». I understand this skepticism. But I have a different angle.
Over the past year, I’ve built several AI tools for my clients: automatic content translation, text generation, post creation, and even an AI assistant with full RAG logic. Connected Claude, OpenAI, Gemini — each time wrote the integration from scratch or through custom plugins. Each time — different request format, different way to store keys, different response handling logic.
If WordPress provides a single standardized way to work with AI providers — it will simplify development. Instead of each plugin reinventing the wheel for storing API keys and routing requests, there will be one interface. One hook. One configuration point.
Another question is how this is implemented. Abilities API, Client Side Abilities, Connectors UI — these are three new abstractions in two minor releases. Isn’t that too much? Time will tell. But the idea itself of built-in AI infrastructure is right.
PHP-only blocks: the most interesting for developers
This is the feature that really gets me excited. WordPress 7.0 allows you to register blocks entirely in PHP. No JavaScript. No React. No build. No npm install. One register_block_type() call — and the block appears in the editor.
How it works: you describe the block attributes in PHP, add the autoRegister flag to the supports array, specify render_callback — and WordPress automatically generates a settings panel in the inspector. String attributes become text fields. Booleans become toggles. Enums become dropdowns. All of this without a single line of JavaScript.
For context: right now, to create even the simplest custom block, you need to write block.json, a React component for the editor, set up a build with @wordpress/scripts, and only then add PHP render or use other workarounds through Advanced Custom Fields, which is what I do now. For a simple block like “banner with CTA” or “author block”, going the block.json route is disproportionately much work.
PHP-only blocks remove this barrier completely. One PHP file. One function. No build process. For WordPress developers who live in PHP and don’t want to dive into the React ecosystem — this is a breakthrough change.
There are limitations. No InnerBlocks support — nested blocks. No rich-text editing directly in the editor — the preview is rendered via ServerSideRender, and each attribute change goes through the REST API. No media file selection through the standard Media Library picker. For complex interactive blocks, this won’t work.
But for 80% of custom blocks I create on client projects — information banners, CTA sections, contact blocks, custom quotes — PHP-only approach will fully satisfy the need. Less code, fewer dependencies, faster development.
New blocks and editor improvements
Besides architectural changes, WordPress 7.0 adds new core blocks and improves existing ones:
- Breadcrumbs and Icons — finally in the core, without third-party plugins
- Navigation Block — rewritten, with support for mobile overlay menus
- Cover Block with video background — you can set a video as the section background
- Grid Block — responsive by default
- Gallery with lightbox — view images in a modal window
- Responsive block visibility — you can hide specific blocks for mobile or desktop out of the box
Regarding responsive visibility — I couldn’t find it right away. Other developers also write that it’s not visible in the playground. Either it works for some blocks only, or it requires additional setup. Will test further.
Video backgrounds for Cover Block and custom CSS directly in the block panel — this is what used to require plugins like Stackable or GenerateBlocks. If this works stably — one fewer plugin on each project and that’s already good!
Image processing in the browser
WordPress 7.0 adds client-side media processing — images are resized and compressed directly in the browser before uploading to the server. Less load on hosting, support for newer formats.
On paper — wonderful. In practice — need to test. How does this work on weak devices? What about large images? Will this crash the browser? I don’t have answers yet, but for clients who upload photos from their phone without any optimization — this is a potentially useful feature.
Security: 6.9.4 reminds us of reality
While everyone discusses 7.0, on March 11 WordPress 6.9.4 quietly came out — a security patch. Three vulnerabilities: path traversal in PclZip, authorization bypass in Notes, and XXE in the getID3 library. And some of them couldn’t be closed on the first try — 6.9.2 and 6.9.3 didn’t fully solve the problem.
This is a reminder: new features are good, but security of existing code is a priority. If you haven’t updated to 6.9.4 yet — do it right now!
Summary
WordPress 7.0 is a major renovation. Walls are being torn down, pipes are being replaced, electricity is being rewired. It’s uncomfortable to live in right now. But if done right — in a year we’ll be thanking for these changes.
Release — April 9. See you then.
