[wp-trac] [WordPress Trac] #46195: is_block_editor() returns false in the block editor

[WordPress Trac]

#46195: is_block_editor() returns false in the block editor
-------------------------------------------------+-------------------------
 Reporter:  Chouby                               |       Owner:  desrosj
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  5.1.2
Component:  Editor                               |     Version:  5.0
 Severity:  normal                               |  Resolution:
 Keywords:  has-patch needs-testing 2nd-opinion  |     Focuses:
                                                 |  administration
-------------------------------------------------+-------------------------
Changes (by desrosj):

 * keywords:  has-patch needs-testing => has-patch needs-testing 2nd-opinion


Comment:

 Ah, you are right. [attachment:"46195.5.diff"] did not account for the
 `replace_editor` filter.

 [attachment:"46195.6.diff"] adds support for plugins using this filter to
 replace the block editor.

 The same issue exists as described above for this filter, though. Because
 the `replace_editor` filter and `use_block_editor_for_post()` function
 require the `WP_Post` instance to be passed, `WP_Screen::get()` can only
 make its best guess as to whether the block editor is used based on the
 default value for the post type being created. So between the
 `current_screen` action and roughly the `load-{$pagenow}` action (which,
 in this case, would be `load-post-new`), the value could be incorrect.

 These are the only scenarios I can think of where this edge case would be
 triggered:

 1. A plugin disables the block editor randomly. This is very unlikely and
 I don't think we should support this.

 2. The block editor is disabled for a user with or without a specific
 capability or meta value. This would cause the value to be inaccurate
 during the time frame detailed above. But, this could be corrected by
 using the `use_block_editor_for_post_type` filter. This is not specific to
 a post, so by using this filter, you are still able to achieve an accurate
 value for `is_block_editor` 100% of the time.

 3. The filter checks for the presence of a certain string in a post title
 or content, or a specific term or meta value to be assigned to a post.
 This would happen only if actions were being performed when the post is
 created using `get_default_post_to_edit()`, which is how the post is
 created in `post-new.php`. This could happen if any of the filters or
 actions within `wp_insert_post()` are used to modify a default post. In
 most cases, this can also be fixed by adding logic to the
 `use_block_editor_for_post_type` filter to detect these scenarios before
 the post is actually created.

 All of these seem like rare edge cases, but they all already exist today.
 They are just buried among much more common scenarios. The changes in
 [attachment:"46195.6.diff"] would greatly narrow the window where
 `is_block_editor` could be incorrect, but these edge cases would still
 exist.

 The patch does not include changes to `edit-form-blocks.php` because the
 [https://core.trac.wordpress.org/browser/tags/5.1.1/src/wp-admin/edit-
 form-blocks.php#L26 code already exists in that file to ensure the current
 screen is correctly flagged as using the block editor].

 Also, I get very nervous changing the load order of the admin area. I
 don't think we can confidently do this in a fully backwards comaptible
 way.

-- 
Ticket URL: <https://core.trac.wordpress.org/ticket/46195#comment:16>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform