[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.1
Component:  Editor                   |     Version:  5.0
 Severity:  normal                   |  Resolution:
 Keywords:  has-patch needs-testing  |     Focuses:  administration
-------------------------------------+-----------------------------

Comment (by desrosj):

 I worked through this with @earnjam today to make sure there were no
 scenarios being missed, and that we are approaching this correctly.

 Here is how the code works in [attachment:"46195.5.diff"]:
 - If a post is being edited, `WP_Screen::get()` will run the post through
 `use_block_editor_for_post()` and set `is_block_editor` to the function's
 return value.
 - If a new post is being edited, the value returned by
 `use_block_editor_for_post_type` for the post type will be set to
 `is_block_editor`.
 - When `edit-form-advanced.php` and `edit-form-blocks.php` are included,
 `is_block_editor` is updated to ensure it is the correct value.

 Looking at the Classic Editor and Gutenberg Ramp plugins, they both seem
 to rely on the `use_block_editor_for_post` filter, which, as @Chouby noted
 above, is only run in `use_block_editor_for_post()` (not in
 `use_block_editor_for_post()`). This means that when a `WP_Screen`
 instance is created when creating a new post, `is_block_editor` could
 incorrectly indicate whether the page is using the block editor.

 The steps noted in the third bullet point above ensure that `WP_Screen`
 has the correct value, but between the `current_screen` action and the
 corresponding edit form file is included, the value ''could'' be
 incorrect. Due to the current order code is executed for an "add new post"
 request, I am not sure if there is a better way.

 The third bullet point would also catch any scenarios where the edit
 advanced/block form files are being included manually.

 @azaozz I'd love your thoughts on this approach as it relates to the
 Classic Editor.

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