WordPress.org

Make WordPress Core

Opened 23 months ago

Closed 22 months ago

Last modified 22 months ago

#45275 closed enhancement (maybelater)

Add a "use_block_editor_for_{post_type}" filter

Reported by: pento Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.0
Component: Editor Keywords: has-patch dev-feedback
Focuses: Cc:

Description

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' );

Attachments (1)

45275.patch (2.7 KB) - added by euthelup 23 months ago.
A shy try in a patch of what I've said above.

Download all attachments as: .zip

Change History (10)

#1 @swissspidy
23 months ago

  • Summary changed from Add a "use_block_editor_for{post_type}" filter to Add a "use_block_editor_for_{post_type}" filter

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.

#2 @euthelup
23 months ago

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
23 months ago

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

#3 @desrosj
23 months ago

  • Keywords has-patch dev-feedback added; needs-patch removed

#4 @pento
22 months ago

  • Milestone 5.0 deleted
  • Resolution set to maybelater
  • Status changed from new to closed

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.

#5 @elliotcondon
22 months ago

@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 );

#6 @jteague
22 months ago

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

#7 @ianatkins
22 months ago

+1 Elliots suggestion - seems more granular and logical.

#8 @deryck
22 months ago

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

#9 @rilwis
22 months ago

@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.

Note: See TracTickets for help on using tickets.