[wp-trac] [WordPress Trac] #52363: use_block_editor_for_post() does not check if post supports editor
WordPress Trac
noreply at wordpress.org
Wed Feb 17 12:39:24 UTC 2021
#52363: use_block_editor_for_post() does not check if post supports editor
--------------------------+-----------------------------
Reporter: gudmdharalds | Owner: (none)
Type: defect (bug) | Status: closed
Priority: normal | Milestone:
Component: Editor | Version: 5.6
Severity: normal | Resolution: wontfix
Keywords: | Focuses: administration
--------------------------+-----------------------------
Comment (by gudmdharalds):
Hi!
I just wanted to comment on this as I felt the concerns in my original
post were not addressed fully.
> So in my opinion current patch will add a redundant check.
>
> Using add_filter( 'use_block_editor_for_post', '__return_true' ); is
like overriding the correct decision already take by WordPress to use
block editor or not. This hook should be used to enabled block editor for
specific post types which are needed.
The check can seem redundant when viewed purely though the scope of
WordPress core and its inner workings.
However, we also need to keep in mind plugins and themes that can override
this filter. In themes and plugins one can invoke the filter in this way,
easily thinking it will enable Gutenberg ''only'' for post types that
support editors:
{{{#!php
add_filter( 'use_block_editor_for_post', '__return_true' );
}}}
This is not be the case. In the case of `attachment` post-types, for
instance, this will lead to white-screens (no editor, no content).
WordPress should try to ''avoid'' these kind of situations by applying the
test found in my patch.
So I would say it is really not redundant, it is simply required to make
sure the editor and the filter functions correctly and fulfill
expectations of those using the filter.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/52363#comment:4>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list