Since WordPress 5.0 and the launch of the block editor, the classic editor has been there… but now the countdown to its farewell has begun.
Remember that you can listen to this program from Pocket Casts, Spotify, and Apple Podcasts or subscribe to the feed directly.
Program transcript
Hello, I’m Alicia Ireland, and you’re listening to WPpodcast, bringing the weekly news from the WordPress Community.
In this episode, you’ll find the information from June 22 to 28, 2026.
The first concrete step in the gradual disappearance of the Classic block has been confirmed: starting with WordPress 7.1, the Classic block no longer appears in the block inserter by default.
This doesn’t affect anything you already have: the block remains registered, any existing Classic block keeps working and being editable exactly as before, and the traditional Classic editor — whether through the Classic Editor plugin or in post types that don’t use the block editor — is not affected at all.
The only thing that changes is you can no longer add a new Classic block from the menu, block library, or slash commands.
The underlying reason is architectural consistency: the Classic block is the only Core block that doesn’t behave like a block, but rather as opaque HTML rendered through an embedded TinyMCE editor, which forces it to be treated as a special case in much of the work done on the block system.
If you need to keep the Classic block available, there’s a specific filter that can be activated globally or conditionally based on post type, and there’s already a small plugin called Enable Classic Block that does exactly that without touching code, already submitted for approval in the plugin directory.
The longer-term goal, which will be addressed in future posts, is for the Classic block to be completely optional and for TinyMCE to only load when it’s actually needed, but that work is outside the scope of WordPress 7.1, leaving the task for WordPress 7.2 or 7.3.
Another interesting merge proposal for WordPress 7.1 details how the Style Guidelines feature will be built underneath. The proposal is to incorporate into core a new post type called Knowledge, designed as a generic piece of storage for site knowledge aimed at both human authors and AI agents. The idea is that instead of each AI plugin inventing its own storage system, permissions, and REST API, WordPress offers a single common foundation — the same way it did with templates and blocks.
Knowledge isn’t a visible feature in itself, but rather the base on which Guidelines is built, which does have its own interface under Settings. The system defines three types of entries: guideline, a source-of-truth text about tone, voice, or image rules that something or someone needs to apply; memory, durable context explicitly stored by the user, like preferences or stable data, always private and owned by its author; and note, free-form working text like sticky notes or drafts. Plugins can register additional custom types, like a terminology glossary. Access is fairly controlled: new entries are private by default, no user type except administrator can manage site-wide entries, and none of this is exposed publicly through front-end queries.
The Core team is quite explicit about what this is not: there’s no AI provider, no model, no retrieval algorithm, no autonomous memory system. What’s being merged is solely the storage and access model; anything resembling relevance, expiration, or memory consolidation stays out of Core and is up to plugins.
And finally, this podcast is distributed under a Creative Commons license as a derivative version of the podcast in Spanish; you can find all the links for more information, and the podcast in other languages, at WPpodcast .org.
Thanks for listening, and until the next episode!
Leave a Reply