Вход на сайт

Просмотр новости

Найдите то, что Вас интересует

The Classic block stays in the inserter for WordPress 7.1

Дата публикации: 07-07-2026 06:22:52

In an earlier post, I announced that the Classic block (core/freeform) would be hidden from the inserter by default starting in WordPress 7.1, accompanied by a new filter and a companion plugin. I’ve decided to revert this change. The Classic block will continue to appear in the inserter in WordPress 7.1, exactly as it does […]

Основное содержимое страницы с новостью.

In an earlier post, I announced that the Classic block Block is the abstract term used to describe units of markup that, composed together, form the content or layout of a webpage using the WordPress editor. The idea combines concepts of what in the past may have achieved with shortcodes, custom HTML, and embed discovery into a single consistent API and user experience. (core/freeform) would be hidden from the inserter by default starting in WordPress 7.1, accompanied by a new filter Filters are one of the two types of Hooks https://codex.wordpress.org/Plugin_API/Hooks. They provide a way for functions to modify data of other functions. They are the counterpart to Actions. Unlike Actions, filters are meant to work in an isolated manner, and should never have side effects such as affecting global variables and output. and a companion plugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory https://wordpress.org/plugins/ or can be cost-based plugin from a third-party..

I’ve decided to revert this change. The Classic block will continue to appear in the inserter in WordPress 7.1, exactly as it does today. There is no change in behavior for users or developers, and no migration Moving the code, database and media files for a website site from one server to another. Most typically done when changing hosting companies. is required.

What this means

  • The Classic block remains available in the inserter by default. You can insert new Classic blocks through the inserter, block library, and slash commands as before.
  • The wp_classic_block_supports_inserter filter has been removed. Because this change never shipped in a stable WordPress release, the filter has no backward-compatibility footprint; there is nothing to migrate away from.
  • The block-level deprecation/migration notice has been removed. The Classic block editing experience returns to what it was previously, including the “Convert to blocks” toolbar action.
  • The Enable Classic Block plugin will be closed. With the default behavior restored, the plugin no longer serves a purpose. If you installed it, you can safely deactivate and remove it; no action is otherwise needed.

Why it is being reverted

After discussing this with a number of people and gathering feedback from different places, it became clear that this approach had things largely backward. It’s one step that makes the experience worse with no direct gain, and it doesn’t really get us any closer to transparently not loading TinyMCE. One of the takeaways is that the Classic block should become obsolete by choice, not by force. I believe time will be better spent to make the alternative genuinely better, while also smoothly, losslessly migrating content, so that users move off Classic block because they want to, not because the door has been removed.

Where the effort goes next

Much of the groundwork from this effort remains valuable, and the intention is to keep pursuing it from a user-first angle:

  • Understanding more in-depth why users still rely on Classic and bridging those gaps
  • Make “Convert to Blocks” flawless – it still has a bunch of flaws and inconsistencies
  • Work on better and more intuitive conversion/migration mechanisms, including mass migration
  • Improve TinyMCE asset registration and allow it to be disabled under various circumstances.
  • Build a mechanism for declaring proper explicit dependency on TinyMCE and work with plugins to utilize it.
  • Continue exploring ways to load TinyMCE on demand / asynchronously, among other performance improvements
  • Not loading TinyMCE on the block editor if the Classic Block is disabled from the block manager

Thank you to everyone who shared feedback and helped course-correct here. This work continues, pointed more squarely at what’s best for users.


Props to @mamaduka for reviewing this post.

#7-1, #dev-notes, #dev-notes-7-1

Схожие новости

#Наименование новостиТональностьИнформативностьДата публикации
1Hiding the Classic block from the inserter in WordPress 7.10723-06-2026
2Merge Proposal: Guidelines built on Knowledge0522-06-2026
3WordPress 7.0.1 RC1 is now available0501-07-2026
4Bug Scrub Schedule for WordPress 7.12403-07-2026
5Merge Proposal: Expanding WordPress Core Abilities0702-07-2026
6WordPress 7.0 Release Retrospective7622-06-2026
7WordPress 7.0 Is Tragic-8617-06-2026
8Reply To: WPS Hide Login Has Completely Broken My WordPress 7.02302-07-2026
9WordPress 7.1 Release Party Schedule0503-07-2026
10Memberlite 7.1: Block-Based Header & Footer Variations5703-07-2026

Классификация: Информация. Схожих патентов: 0. Схожих новостей: 10. Тональность: 0. Информативность: 5. Источник: make.wordpress.org.