Block Library: Deprecate Classic Block and TinyMCE

[tyxla]

Goal

To deprecate and later remove the Classic Block (making it fully opt-in), and lay the groundwork towards making TinyMCE also fully opt-in.

Rationale

We recently started hiding (#77911) the Classic Block from the inserter, but this is just the first step on a long path.

Why make Classic Block opt-in

1. Hiding from the inserter only addresses the inflow. It stops new Classic blocks from being created, but the per-load tax is unchanged: every editor still registers core/freeform, hydrates its edit component, and pulls the TinyMCE-bridging modal into the block-library bundle. On a site with zero Classic content, that's all dead weight.
2. Architectural consistency - every other block in Core is a pure block-tree node. Freeform is the lone exception - opaque HTML rendered through a separate editor. Keeping it in the default registry contradicts the block-first model.
3. Classic usage is shrinking. New Classic blocks will no longer be insertable by default. The convert-to-blocks feature has been the migration path for years. The set of posts that need Classic block registered is finite and getting smaller - a precondition for safely flipping registration off by default.
4. Maintenance leverage - every block-library refactor has to special-case core/freeform. Each carve-out is small; the cumulative cost is real.
5. It paves the road for loading TinyMCE on demand. Classic Block is the only consumer of window.tinymce / window.wp.oldEditor in Gutenberg. As long as Classic is registered by default, Core has no signal it can use to skip TinyMCE on the post screen.

Why make TinyMCE opt-in

1. It's probably the largest single asset Core ships to the post screen that the modern editor doesn't otherwise need.
2. The implicit-global API surface (window.tinymce, window.wp.oldEditor, window.wpEditorL10n.tinymce) is read by an unknown number of plugins. Loading it by default keeps that API alive forever. Loading it on demand makes the dependency explicit and auditable.
3. It's already conditional in spirit. Core's _WP_Editors::enqueue_default_editor() was designed around an era when every post screen needed a WYSIWYG fallback. That premise is gone for block-editor screens.

Plan and next steps

• Hide the Classic block
  • Hide from the inserter by default Classic Block: Unwrap experiment to hide it from inserter #77911
  • Introduce filters and a plugin to opt into showing it in the inserter Disable Classic block: Control inserter support via filter #77845
• Experiment 1: Deprecate the Classic Block
  • Make the Classic block appear visually close to the Missing block - Experiment: Add Classic block migration notice #78090
  • Introduce a "Convert to Custom HTML" button - Experiment: Add Classic block migration notice #78090
  • Consider adding any additional migration paths for the existing Classic block instances
  • Improve "convert to blocks" functionality ("Convert to Blocks" fails if the block is not allowed by 'allowed_block_types_all' #66620)
  • Make available for everyone (remove the experiment wrapper)
  • Aim to make this part of WordPress 7.1.
• Experiment 2: Remove the Classic Block
  • Deregister the Classic block
  • Introduce a plugin that registers the Classic block as an opt-in mechanism
  • Adding "convert to blocks" and "convert to html" in the Missing block
  • Make available for everyone (remove the experiment wrapper)
  • Aim to make this part of a future WordPress release (7.2 or in the future)
• Additional related work
  • Finish the move of freeform to its own package: Move freeform block to separate package #70603
  • Cleanup old TinyMCE / classic block compatibility layers
  • Experiment with making core/html block to be the default instead of core/freeform
• Make TinyMCE opt-in (long-term)
  • Update all TinyMCE assets to be enqueued and loaded the traditional way, ensuring the classic editor still works
  • Conditionalize/fix any usages in core that rely on TinyMCE to always be loaded
  • Work with the plugins using TinyMCE to start enqueueing it explicitly
  • Dequeue TinyMCE assets while leaving them registered
  • Aim to make this be tested thoroughly and land in a future WordPress release

[BlackStar1991]

It's very bad idea. Our team don't use Gutenberg blocks for our projects. We turn off block system.
Just because you don't use the “Classic Editor” doesn't mean that millions of other websites don't use it either

[pattonwebz]

@BlackStar1991 the classic editor experience would be unchanged with this here. This is just a path for removing the code that puts the classic block into the block editor.

TinyMCE and it's classic editor experience would still remain available if the block editor is not being used (which will remain the case for any post types which do not have rest enabled).

[tyxla]

It's very bad idea. Our team don't use Gutenberg blocks for our projects. We turn off block system.
Just because you don't use the “Classic Editor” doesn't mean that millions of other websites don't use it either

@BlackStar1991 just like @pattonwebz explained above, the classic editor will still remain in WordPress after this change. The plan here affects only the block editor, and if you're not using it, you won't feel/see any difference. It's similar for the underlying TinyMCE - it will eventually become opt-in, but will be enabled for the Classic Editor.

[Mamaduka]

It would be nice to fix some of the "Covert to Blocks" issues. Here's a good example - #66620. If converting doesn't work well, that would increase the number of support requests.

[tyxla]

That's reasonable, thanks @Mamaduka. Added to the list so we can consider any potential improvements in that area.

[nickma1]

There are some functions in the classic block (such as indenting and double indenting paragraphs) that are not available in other block types. With the phase out of classic blocks in the block editor, will I be able to access any of these functions without switching the entire post from block to classic editor?

[tyxla]

There are some functions in the classic block (such as indenting and double indenting paragraphs) that are not available in other block types. With the phase out of classic blocks in the block editor, will I be able to access any of these functions without switching the entire post from block to classic editor?

@nickma1 We're always happy to consider adding features to the block editor (especially if they're filling a broad user gap), but if I understand your use case correctly, line indenting is already part of Gutenberg (since version Gutenberg 22.6) and will be part of WordPress 7.0 (to be released in less than 2 weeks). Paragraph blocks will support line indent by default, and any block can declare support for it. Here's what it looks like:

Screen.Recording.2026-05-09.at.22.15.25.mov

You can read more about it here:

• GitHub issue: Add text indentation support at paragraph block type level #37462
• Implementation: Add Line Indent support. #73114 and Block Supports: Add Line Indent support using enum setting #74889
• WordPress 7.0 feature post: https://make.wordpress.org/core/2026/03/15/new-block-support-text-indent-textindent/

Any other missing features in mind?

[nickma1]

There are some functions in the classic block (such as indenting and double indenting paragraphs) that are not available in other block types. With the phase out of classic blocks in the block editor, will I be able to access any of these functions without switching the entire post from block to classic editor?

@nickma1 We're always happy to consider adding features to the block editor (especially if they're filling a broad user gap), but if I understand your use case correctly, line indenting is already part of Gutenberg (since version Gutenberg 22.6) and will be part of WordPress 7.0 (to be released in less than 2 weeks). Paragraph blocks will support line indent by default, and any block can declare support for it. Here's what it looks like:

Screen.Recording.2026-05-09.at.22.15.25.mov
You can read more about it here:

• GitHub issue: Add text indentation support at paragraph block type level #37462
• Implementation: Add Line Indent support. #73114 and Block Supports: Add Line Indent support using enum setting #74889
• WordPress 7.0 feature post: https://make.wordpress.org/core/2026/03/15/new-block-support-text-indent-textindent/

Any other missing features in mind?

Thank you, I actually have been using the Wordpress 7.0 beta version and can see this feature, but I am trying to indent entire paragraphs (not just the first line). It looks like there may be a way to use padding/ margins on blocks to produce the same effect, but I don't see this as an option either.