Add a "use_block_editor_for_{post_type}" filter

[pento]

Per @westi's ​comment, it would be helpful to create a use_block_editor_for_{post_type} filter, which would allow a single post type to be more reliably filtered.

For example, a post type called blocks-are-bad-okay could remove block editor support like so:

add_filter( 'use_block_editor_for_blocks-are-bad-okay', '__return_false' );

[swissspidy]

Dynamic filters in core usually pass that dynamic part as an argument as well, meaning that in this case the flag and the post type would be passed as arguments.

That would clash with the existing use_block_editor_for_post filter that passes the flag and the post object as arguments.

[euthelup]

Interesting topic and a good improvement IMO since a composed action/filter may get called if it's needed or not, but an action/filter served with a parameter will always get a hit.

I think the case of use_block_editor_for_post is a little bit weird since it doesn't really check if a post uses the block editor, it checks if a request through the post.php or post-new.php file does it or not.

Plus, from what I can understand from the code, use_block_editor_for_post uses and overwrites the effect of use_block_editor_for_post_type so maybe this is just a poor naming for the use_block_editor_for_post hook?

I'm thinking of a solution, but I'm not sure if it's too much of a hassle before a big release:

1) Deprecate use_block_editor_for_post and use_block_editor_for_post_type filters and make them use new(next) functions and filters. But we need to keep them because I think that some plugins are using them.

2) Create a use_block_editor function+filter which will take the ultimate decision to use the block editor or not for all the post types (similar to what use_block_editor_for_post does now).

3) Create a use_block_editor_for_{post_type} filter and make use_block_editor_for_post_type fallback on it.

I'm not sure about the deprecations tho, but maybe it's better to have a clear hooks hierarchy before releasing them in the wild.

[euthelup]

A shy try in a patch of what I've said above.

[pento]

Thank you for the patch, @euthelup.

This was an interesting idea, but I don't think the utility of this additional way of filtering will outweigh the effort required to maintain it.

[elliotcondon]

@pento Please reconsider adding in this filter. I don't see how there is any effort to maintain it.

This is a single line of code in core that both optimizes all 3rd party plugins and could even avoid a "snowball" issue due to bad 3rd party code.

Please change:

/**
	 * Filter whether a post is able to be edited in the block editor.
	 *
	 * @since 5.0.0
	 *
	 * @param bool   $use_block_editor  Whether the post type can be edited or not. Default true.
	 * @param string $post_type         The post type being checked.
	 */
	return apply_filters( 'use_block_editor_for_post_type', true, $post_type );

to:

/**
	 * Filter whether a post is able to be edited in the block editor.
	 *
	 * @since 5.0.0
	 *
	 * @param bool   $use_block_editor  Whether the post type can be edited or not. Default true.
	 * @param string $post_type         The post type being checked.
	 */
	$use_block_editor = apply_filters( "use_block_editor_for_post_type", true, $post_type );
	return apply_filters( "use_block_editor_for_{$post_type}", $use_block_editor );

[jteague]

I'm not seeing an overhead issue by implementing @elliotcondon's proposal, and the value is there. +1

[ianatkins]

+1 Elliots suggestion - seems more granular and logical.

[deryck]

I think it's a good idea. There'll be a certain "very simple content" custom post in which we don't want Guttenberg. Leave to client choice is too risky. +1

[rilwis]

@euthelup: the naming seems to be bad at the moment. However, when Gutenberg is used for other places such as widgets or menus, the part for_post and for_post_type is needed to make less confusion.

@pento: I agree to add this filter to the core. It helps writing the code to disable Gutenberg on some parts of the website much easier.