Disable Classic block: Control inserter support via filter#77845
Conversation
775b52e to
710c62f
Compare
710c62f to
61aa520
Compare
|
The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
| function gutenberg_register_block_library_script_special_case( $scripts ) { | ||
| $handle = 'wp-block-library'; | ||
| $script = $scripts->query( $handle, 'registered' ); | ||
| if ( |
There was a problem hiding this comment.
The block is no longer registered conditionally, so this dependency doesn't need to be conditional either - editor is required whenever the Classic block can render, which is now always.
tyxla
left a comment
There was a problem hiding this comment.
Confirming the filter works well, and the block is hidden from the inserter (including in block visibility settings) by default, while existing Classic block instances continue to work regardless.
🚢
|
I think this could use a dev note for the new filter, btw. Especially considering that we're planning to remove the experimental wrapper before 7.1 ships. |
|
The dev note here is outdated. It's been posted in #77911 (comment). |
|
Posted a dev note for once the experiment wrapper is removed. |
|
Nice work! Do we have a tracking issue related to this effort? |
|
@Mamaduka, there's been a fair amount of work on it this week. Thanks - a tracking issue makes sense - we'll add one next week. |
|
@Mamaduka, actually, I realized we're about to wrap up the experiment: #77911, so opening a tracking issue won't be necessary for that one. We are considering working on some more aggressive handling of the Classic block, with some ideas like:
Before we start working on those, we will make sure to add a tracking issue. Does that make sense? |
|
@tyxla, it does, and I trust your judgment here. It would also be good to go through Classic block issues/PRs and close ones that no longer make sense. |
Yeah, that's a good call. For the protocol, I don't envision many of the issues would be affected, since the block will continue to be active and always registered for the time being - we're just hiding it from the inserter. |
* Disable Classic block: Control inserter support via filter * Fix PHPCS short ternary error * Always declare editor dependency for wp-block-library
|
I just cherry-picked this PR to the release/23.1 branch to get it included in the next release: 08b3beb |
What?
Add a
gutenberg_classic_block_supports_inserterfilter to control whether the Classic block is available in the inserter. Defaults tofalse.The previous post-content check is no longer necessary. Since we switched to registering the Classic block unconditionally in #77840, existing posts that use the Classic block will continue to work - we just don't allow new instances to be inserted.
Why?
Previously, the Classic block was made available in the inserter when the post being edited already contained one. For the experiment, we want a stricter default - hide the Classic block from the inserter, and let developers opt in explicitly.
How?
The Classic block's inserter visibility is now driven by a single PHP filter. The result is exposed to JS through the existing
window.wp.needsClassicBlockflag, which the block reads viasupports.inserter. The filter receives the post being edited (or null) so callbacks can decide based on context.Testing Instructions
mu-plugins:Testing Instructions for Keyboard
Screenshots or screencast
N/A
Use of AI Tools
Cursor with Opus 4.7