Key Takeaways
- WordPress 7.0 was delayed to 20 May 2026 to allow stability testing of real-time collaboration – a genuinely significant feature that needed to be done right.
- The admin modernisation is long overdue and genuinely welcome. DataViews, DataForms, and a consistent design system finally make the backend feel like software built this decade.
- Real-time collaboration is the headline feature that actually matters for small business owners working with copywriters, bookkeepers, or virtual assistants.
- I am dropping Divi from my development stack. Clients don't use it, it makes builds unnecessarily expensive, and raw WordPress themes work far better with modern AI development tools.
- WordPress's own AI features are a marketing story, not a professional development tool. Meaningful AI-assisted WordPress development happens outside the CMS, using external agentic environments and WP CLI.
WordPress 7.0 was originally scheduled for 9 April 2026. It didn’t make it. The release was paused mid-cycle while contributors worked through architectural problems with real-time collaboration – the headline feature that allows multiple people to edit the same post simultaneously, like Google Docs inside WordPress. A revised schedule was confirmed on 22 April, with the new release date set for 20 May 2026.
That delay matters less than what caused it. The WordPress core team made a deliberate choice to get real-time collaboration right rather than ship it broken. That’s the right call – especially for a feature that, as I’ll explain, is one of the few new additions in this release that genuinely affects how small businesses use their websites.
But before I get into what WordPress 7.0 actually delivers, I need to be honest about something bigger. My own development practice has changed significantly since I last wrote about WordPress page builders. That change shapes how I think about everything in this release.
I Am Dropping Divi
In an earlier article, I described my workflow as a hybrid: using Divi’s Theme Builder for site-wide template design, with the Classic Editor re-enabled for day-to-day content writing. At the time, I called it "the professional’s workflow" and genuinely meant it.
I’ve changed my mind.
The problem with Divi is not the quality of the tool – it’s still capable software. The problem is that it only justifies its presence in the stack if the client is going to use it. And my clients don’t. They want a clean editor for writing content. They want to update a page heading or swap out an image. They are not interested in mastering a visual page builder, and they shouldn’t need to be.
What a visual page builder like Divi actually solves is the template-design problem: building the headers, footers, post layouts, and archive grids that determine how content is presented. That’s a developer’s job, not a client’s. And if the template-design work sits firmly on my side of the table anyway, I don’t need a drag-and-drop GUI to do it – I need a clean theme architecture and good tools.
Those good tools now exist, in the form of AI agentic coding environments. I can build and modify raw WordPress theme templates faster than I can configure Divi’s visual interface. The code is lighter, the output is cleaner, and there is zero visual-builder overhead loading on every page. For my clients, a raw WordPress theme with a simple Classic Editor means faster load times, simpler maintenance, and no lock-in to a third-party product roadmap.
Dropping Divi also removes a layer of complexity from the development process entirely. Raw WordPress themes are easier for AI coding agents to read and modify accurately. They work directly with PHP templates, WordPress hooks, and standard CSS – precisely the patterns that agentic tools like GitHub Copilot agent mode handle well. Introducing a page builder layer adds proprietary abstractions that interrupt that workflow.
The Admin Modernisation: Actually Overdue
WordPress’s administration interface has felt visually stranded for years – a patchwork of interfaces added across different eras, each with its own visual language and interaction patterns. WordPress 7.0 takes the most significant step yet toward fixing that.
The underlying architecture here is DataViews and DataForms – a unified data-display and form system that has been progressively rolling out through recent Gutenberg plugin releases. In WordPress 7.0, it lands in core. The effect is a post list, a settings panel, or a media library that all behave consistently, respond to filtering and sorting in the same way, and look like they were designed by the same team in the same year. That sounds like an internal concern, but it has real effects: a client who manages their own blog posts or product listings now has an interface that is noticeably easier to navigate.
The design system itself – a new default colour scheme, consistent spacing, updated component styles – is the visual side of the same improvement. I’ve been privately criticising WordPress’s admin aesthetics for years. I’m happy to acknowledge when the right things are happening, and this is one of them.
Real-Time Collaboration: The Feature That Took the Release Hostage
Real-time collaboration is the Google Docs moment for WordPress. Multiple users editing the same post simultaneously, with each person’s cursor and changes visible in real time, without overwriting each other’s work.
This is the feature that caused the April delay. The core team discovered that concurrent edits to complex content – tables, nested blocks, array-type attributes – produced conflicts that were not handled gracefully. They spent the additional weeks resolving those edge cases before committing to a public release.
For most small businesses, this feature will sit dormant. A sole trader managing their own website doesn’t need simultaneous multi-user editing. But for businesses that bring in a copywriter to update pages, work with a virtual assistant to manage blog content, or collaborate with a marketing consultant – this has practical value. The previous workflow involved emailing Word documents back and forth, or one person making changes while the other waited. WordPress 7.0 removes that friction.
New Blocks: The Direction I Would Not Have Chosen
WordPress 7.0 ships several new blocks: Accordion, Breadcrumbs, Icon, Math, Post Time to Read, and a Term Query block family. The Verse block has been renamed Poetry.
These are technically competent additions. Accordion – expandable/collapsible content sections – is a genuinely common interface pattern. Breadcrumbs are a basic navigation aid. Icon is useful for visual design. None of this is wrong.
What I object to is the direction it points. Each new block that adds layout and interaction capability to the content editor asks a business owner to do more design work inside their posts and pages. Every accordion section, every icon-labelled feature grid, every decorative element a client adds to their content becomes something I have no control over – and something they have to learn to use correctly to avoid breaking the visual consistency of their site.
The right model is still the one I described in that earlier article: a clean separation between template (what the page looks like) and content (what the page says). The template is built once, by a designer. The content is written on an ongoing basis, by the business owner. Giving clients more visual-building tools inside the post editor blurs that line. It shifts responsibility for design decisions onto people who did not sign up to be designers, and whose time is better spent running their businesses.
I keep coming back to the same conclusion. The best interface WordPress has ever shipped for content creation is a clean editor with a blinking cursor. The Classic Editor understood this. For all of Gutenberg’s genuine improvements to template-level block editing, its extension into the content-creation layer remains a problem the project has not fully solved.
WordPress’s AI Features: A Marketing Story
WordPress 7.0 includes the WP AI Client API – a standardised interface that lets WordPress core and plugins communicate with AI models in a uniform way. The design principle is explicitly “no providers in core”: WordPress doesn’t bundle an AI service, it defines how plugins that do bundle AI services should talk to the rest of the system.
That’s a sensible architecture decision. But it is primarily a foundation for the plugin and theme ecosystem, not a feature you will notice as a site owner. Plugins can now write AI-powered features that connect to whatever service you configure – OpenAI, Anthropic, a self-hosted model – without each plugin needing its own custom integration. It is plumbing, not furniture.
What this creates is a commercial opportunity for plugin and theme developers to add AI features to their products. Some of those features will be genuinely useful. Content rewriting tools, image alt-text generation, spelling and grammar assistance in the editor – these are reasonable applications. The AI-in-WordPress story being sold to business owners is mostly this: lightweight, maintenance-oriented assistance that helps non-technical users do things they already needed to do.
What it is not is a professional development tool. I have watched AI writing assistance built into CMS interfaces for long enough to say clearly: they are underdeveloped compared to what is available outside those systems. The AI writing tool baked into a WordPress plugin is not competing with a dedicated agentic development environment. It is competing with pressing the spell-check button. That is a reasonable thing to compete with. It is not revolutionary.
How AI Actually Improves WordPress Development
The meaningful AI story for WordPress is not inside the CMS – it is the external agentic environment that operates on WordPress files, database records, and server state through standard interfaces.
My own workflow, which I described in a previous article on building custom plugins with AI agents, relies on GitHub Copilot agent mode in VS Code operating on raw WordPress PHP, interacting with a running WordPress install through WP CLI. That workflow – read the codebase, understand the hooks, write the code, run the tests, deploy the change – is how AI genuinely accelerates WordPress development. It works because WordPress has excellent command-line tooling and a well-documented hook system that AI models understand deeply.
The hypothetical WordPress AI feature that would genuinely interest me professionally is native WP CLI integration with an agentic system – the ability to describe a site change in natural language and have an agent query the database, modify templates, and verify the result, all from the command line. WordPress’s own AI experiments have not gone in that direction. They have gone in the direction of writing assistance inside the post editor, because that is what the plugin ecosystem can monetise.
For my clients, this distinction matters in a specific way. The AI that benefits them most is not inside WordPress. It is the AI I use to build and maintain their sites faster and more accurately than I could without it – which translates directly to lower project costs, leaner codebases, and more time spent on design and strategy rather than boilerplate.
What WordPress 7.0 Means for Your Website
If you are a client of mine, the changes in WordPress 7.0 are mostly transparent. The admin interface will look more polished and behave more consistently. If you share your WordPress login with a team member, copywriter, or assistant, real-time collaboration is genuinely useful. The new blocks are there if you want them, but I will not be building layouts that require clients to use them without a good reason.
The bigger change is the one happening in my own practice. Moving to raw WordPress themes and away from third-party visual builders means leaner sites, cleaner code, and a development workflow that takes full advantage of the AI tools that have genuinely transformed what I can build in a day. That is the change worth communicating to you – not because it changes what your website looks like, but because it changes what I can do for you, and how efficiently I can do it.
If you are thinking about a new website, a redesign, or just want to understand what the right technology stack looks like in 2026, let’s have a conversation. The short version: simpler is better, separation of content and design still matters, and the best AI tools for WordPress are not the ones WordPress ships.
