WordPress.org

Make WordPress Core

Opened 5 weeks ago

Closed 11 days ago

Last modified 7 days ago

#52363 closed defect (bug) (wontfix)

use_block_editor_for_post() does not check if post supports editor

Reported by: gudmdharalds Owned by:
Milestone: Priority: normal
Severity: normal Version: 5.6
Component: Editor Keywords:
Focuses: administration Cc:

Description

The current implementation of the use_block_editor_for_post() function in WordPress 5.6 (and trunk) does not check if the post-type in question supports editor. This can lead to situations where the Gutenberg Editor is being loaded for a particular post which does not support an editor, resulting in a JavaScript error and a white screen.

Note that while use_block_editor_for_post_type does perform this check, that is not enough, as the use_block_editor_for_post filter is applied later.

To replicate:

  1. Set up WordPress 5.6 with no plugins active and default theme activated.
  1. Add add_filter( 'use_block_editor_for_post', '__return_true' ); to a file in wp-content/mu-plugins.
  1. Edit any post item of type post, verify that Gutenberg loads successfully.
  1. Add image to Media Library, note the ID of it.
  1. Attempt to edit the newly uploaded image by navigating to: wp-admin/post.php?post=ID&action=edit -- replace ID with ID of the image.
  1. White screen should appear, with JavaScript error: Uncaught (in promise) TypeError: Cannot read property 'raw' of undefined [...]

This occurs is because the attachment post-type does not support the Gutenberg Editor.

This behaviour does not happen when using the filter use_block_editor_for_post_type, as the function that calls the filter checks if the post-type supports editors. The same kind of check should be performed when using the use_block_editor_for_post filter to avoid unexpected errors. Users of the filter would assume that Gutenberg is not loaded if it is not supported by the post-type.

Expected behavior: Gutenberg is not loaded for post-types not supporting editor, even if the use_block_editor_for_post filter is used as described above.

Observed behavior: White screen, unable to do editing.

Attachments (1)

use-block-editor-for-post.diff (523 bytes) - added by gudmdharalds 5 weeks ago.
Patch to check for editor support

Download all attachments as: .zip

Change History (6)

@gudmdharalds
5 weeks ago

Patch to check for editor support

#1 @SergeyBiryukov
5 weeks ago

  • Milestone changed from Awaiting Review to 5.7

#2 follow-up: @anand.au14
12 days ago

@gudmdharalds

Function use_block_editor_for_post is calling function use_block_editor_for_post_type to check if block editor can be used for that post type.

And use_block_editor_for_post_type is already checking if that post type supports editor.

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.

Last edited 11 days ago by anand.au14 (previous) (diff)

#3 in reply to: ↑ 2 @peterwilsoncc
11 days ago

  • Keywords has-patch removed
  • Milestone 5.7 deleted
  • Resolution set to wontfix
  • Status changed from assigned to closed

Replying to anand.au14:

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.

I agree, the use of the use_block_editor_for_post filter in this manner is a developer error and overriding the correct decision made by WordPress already.

I'm going to close this as wontfix as bypassing the filter for post types that don't support the block-editor could break sites using API middleware.

#4 @gudmdharalds
11 days ago

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:

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.

Last edited 7 days ago by SergeyBiryukov (previous) (diff)

#5 @peterwilsoncc
9 days ago

I do hear your concerns, I really do, but it's the nature of systems with a plugin architecture that for things to remain flexible the system needs to allow plugins to make mistakes.

If a plugin returns true (ie, use the block editor) for an attachment there isn't a way for WordPress to know if it's a mistake or if the plugin developer has rewritten the attachment screen to work in the block-editor.

It would be nice if WordPress could protect against mistakes, but in order to allow developers make terrific improvements WordPress also needs to allow them to make mistakes, even quite serious ones.

Note: See TracTickets for help on using tickets.