Introduction
If you learned WordPress before 2018, you learned it on TinyMCE: a white box, a formatting toolbar, and shortcodes for anything fancier than bold text. If you learned WordPress after 2022, you have probably never touched that interface at all. In between sits one of the biggest interface changes any major CMS has made without losing its user base, and it is still happening. WordPress 7.0, released in May 2026, adds a native AI layer on top of the block editor that changes what “building a page” even means.
This is a practical look at how the WordPress block editor evolved from a single text box into an AI-assisted design tool and what each stage actually changed for the people building sites day to day.

The Classic Editor: A Text Box That Did One Thing Well
For roughly 15 years, WordPress content was written in a WYSIWYG (What You See Is What You Get) field built on TinyMCE, the same rich-text library used in countless other web apps at the time. It handled paragraphs, headings, bold and italic text, and links. Anything beyond that, columns, galleries, buttons, pricing tables, meant either raw HTML/CSS, a shortcode from a plugin, or a page builder bolted on top like Visual Composer or Elementor’s early versions.
The Classic Editor was fast, predictable, and lightweight, which is exactly why so many production sites still run on it today. Its limitation was that layout and content were separate problems: the editor handled words, and everything else was a workaround.
Gutenberg: WordPress Rebuilds Its Editor Around Blocks
Gutenberg shipped with WordPress 5.0 on December 6, 2018, and replaced TinyMCE as the default editor — this was the moment the modern WordPress block editor was born. Instead of one text field, every piece of content, a paragraph, an image, a button, a column, became its own block with its own settings panel. It was a genuinely disruptive change, and the initial reaction from a large part of the WordPress community was not positive; the Classic Editor plugin, released alongside 5.0 to let sites opt out, was installed on millions of sites and remains active on a meaningful share of the ecosystem years later.
What Gutenberg actually solved, once teams adjusted to it, was the layout problem the Classic Editor never addressed, a shift documented in detail in the official Block Editor Handbook. Columns, media-text blocks, and reusable block patterns meant page structure lived inside core WordPress instead of inside a third-party page builder’s proprietary shortcodes, which had always been a long-term maintenance risk.
Full Site Editing: Blocks Take Over the Whole Site
Gutenberg’s first version only touched post and page content; headers, footers, and sidebars were still theme template files written in PHP. That changed with Full Site Editing, previewed in WordPress 5.8 (2021) and shipped as a core feature in WordPress 5.9 in January 2022. Block themes, the theme.json configuration file, and the Site Editor extended block-based editing to templates, navigation, and global styles, the entire site, not just the content area.
This is the point where the gap between “using WordPress” and “writing PHP templates” mostly closed for everyday site building in the WordPress block editor. A theme built on FSE principles can have its header, footer, and archive templates edited visually, no template files required.
WordPress 7.0: AI Becomes Part of Core, Not a Plugin
WordPress 7.0 (“Armstrong”), released May 20, 2026, is the next structural shift. Rather than leaving AI features to individual plugins with incompatible APIs, WordPress core now ships a shared AI infrastructure layer: the Connectors API and the WP AI Client, a provider-agnostic PHP API built on top of the Abilities API introduced in WordPress 6.9. Plugins can send prompts to AI models and get results back through one consistent interface instead of each plugin shipping its own integration.
In practice, this shows up as a handful of concrete features: Content Assistant for AI-powered writing and editing directly inside Gutenberg, Site Agent for natural-language site administration, Workflow Automation for AI-driven repetitive tasks, and an AI Playground for testing different models and providers. WordPress also shipped an MCP (Model Context Protocol) Adapter, which lets external AI agents interact with a WordPress site programmatically. That is a meaningfully different idea from “AI writes your blog post” — it is AI as an infrastructure layer the rest of WordPress can plug into.
What This Means If You’re Still Running the Classic Editor
WordPress still powers roughly 43% of all websites and over 590 million active sites (see our full breakdown of where WordPress is headed in 2026), and a meaningful share of that install base has never migrated off the Classic Editor. That is not automatically a problem: a fast, simple, content-only site has little to gain from a block-based rebuild. The calculation changes once you want AI-assisted content workflows, since Content Assistant and Site Agent are built for the block editor, not the Classic Editor’s text field.
Migrating into the WordPress block editor is rarely a clean one-click process. Shortcode-heavy content needs to be converted to blocks, custom page-builder layouts need to be rebuilt as block patterns, and any theme relying on classic PHP templates needs a block theme (or a hybrid setup) to take advantage of the Site Editor.
How Dazzlebirds Approaches These Migrations
When we take on a classic editor to block editor migration, we do not touch content and theme structure in the same pass. Content gets converted and validated block by block first, then we address theme templates and Full Site Editing separately, since mixing the two steps is where most migrations lose formatting or break custom layouts. AI features get added last, once the underlying block structure is solid, because Content Assistant and Site Agent are only as reliable as the block markup underneath them. If your team needs hands-on help with a migration, our WordPress plugin developers handle exactly this kind of structural rebuild.
Conclusion
The move from a single text box to an AI-assisted, block-based publishing system took about eight years and three distinct core releases: Gutenberg in 2018, Full Site Editing in 2021-2022, and native AI infrastructure in WordPress 7.0. Each stage solved a real limitation of the one before it. Whether it is worth migrating an existing Classic Editor site depends less on chasing the newest release and more on whether your team will actually use what the new layer unlocks.
FAQs
Gutenberg, WordPress’s block-based editor, replaced the Classic Editor as the default in WordPress 5.0 on December 6, 2018. The Classic Editor plugin still lets sites opt out, and it remains active on a meaningful share of the WordPress ecosystem today.
Full Site Editing (FSE) extends block-based editing beyond post content to templates, headers, footers, and global styles. It was previewed in WordPress 5.8 (2021) and shipped as a core feature in WordPress 5.9 in January 2022, built around block themes and the theme.json configuration file.
WordPress 7.0 ("Armstrong," released May 20, 2026) adds a native AI infrastructure layer built on the Connectors API and the WP AI Client SDK. On top of that sit Content Assistant for AI-powered writing inside Gutenberg, Site Agent for natural-language site administration, and Workflow Automation for repetitive tasks.
It depends on what you need. A simple, content-only site has little to gain from a block-based rebuild. But if you want AI-assisted content workflows or Full Site Editing, migrating is worth it, since Content Assistant and Site Agent are built specifically for the block editor, not the Classic Editor’s text field.
It is rarely a one-click process. Shortcode-heavy content needs converting to blocks, custom page-builder layouts need rebuilding as block patterns, and classic PHP-templated themes need a block theme to take advantage of the Site Editor. Handling content and theme structure in separate passes avoids most formatting breaks.