[wp-trac] [WordPress Trac] #63086: Customizer: notice errror regarding WP_Theme::is_block_theme

[WordPress Trac]

#63086: Customizer: notice errror regarding WP_Theme::is_block_theme
-------------------------------------------------+-------------------------
 Reporter:  wildworks                            |       Owner:  joemcgill
     Type:  defect (bug)                         |      Status:  assigned
 Priority:  normal                               |   Milestone:  6.8
Component:  Customize                            |     Version:  trunk
 Severity:  normal                               |  Resolution:
 Keywords:  has-testing-info has-patch dev-      |     Focuses:
  feedback                                       |
-------------------------------------------------+-------------------------

Comment (by dinhtungdu):

 Replying to [comment:23 joemcgill]:

 Thanks for your explanation. You're right about must use plugins, they're
 loaded before theme directory registration, so it's possible for plugins
 to call `wp_is_block_theme()` before theme directory registration and
 break the theme resolution.

 >  That's why I think moving the warning there, instead of the `WP_Theme`
 method would be more appropriate.

 This is the safer and less disruptive approach than having the early
 return in the `WP_Theme::is_block_theme()` which breaks the Site Editor
 for block themes if `wp_is_block_theme()` is called before theme directory
 registration. Moving it out of the method prevents that critical issue.
 I’m sharing my investigation on that topic below in case anyone is
 interested.

 Why does having an early return in `WP_Theme::is_block_theme()` and
 calling `wp_is_block_theme()` before [https://github.com/WordPress
 /wordpress-develop/blob/32fe6af9c36e2b80e79a664fc6ae53d9c5cd3f9a/src/wp-
 settings.php#L519 theme directory registration] breaks the Site Editor?
 1. When the method is called, the first thing that happens is `WP_Theme`
 initialization. We care about [https://github.com/dinhtungdu/wordpress-
 develop/blob/001a86a7ca833535533e59dc59babddc50fe2afa/src/wp-includes
 /class-wp-theme.php#L395-L418 these lines] particularly, as there is a
 call to `WP_Theme::is_block_theme()`.
 2. If this logic runs too early (before theme directory registration),
 `WP_Theme::is_block_theme()` returns `false`, and an error is set for the
 block theme (which doesn’t have `index.php`). The instance is cached for
 later use.
 3. During Site Editor initialization, we need to preload some REST API
 routes, specifically, the [https://github.com/dinhtungdu/wordpress-
 develop/blob/34c6de73a142db1872913a863938c8492814a109/src/wp-admin/site-
 editor.php#L189 theme route].
 4. The response for this route will be empty (instead of the active theme
 data) because of the error mentioned in point 2 above:
    1. `wp_get_themes()`  only returns [https://github.com/dinhtungdu
 /wordpress-develop/blob/001a86a7ca833535533e59dc59babddc50fe2afa/src/wp-
 includes/theme.php#L92-L98 themes without error], which means that the
 current block theme with error isn’t included in the returned data.
    2. Because of that,`WP_REST_Themes_Controller::get_items()` will
 [https://github.com/dinhtungdu/wordpress-
 develop/blob/001a86a7ca833535533e59dc59babddc50fe2afa/src/wp-includes
 /rest-api/endpoints/class-wp-rest-themes-controller.php#L197-L220 return
 an empty array].
    3. The Site Editor will be broken because of the missing active theme
 data.

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