[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:
 Severity:  normal                               |  Resolution:
 Keywords:  has-testing-info has-unit-tests      |     Focuses:
  needs-patch needs-testing                      |
-------------------------------------------------+-------------------------

Comment (by joemcgill):

 Replying to [comment:14 dinhtungdu]:
 > From my investigation, I believe that it's safe for plugin to call
 `wp_is_block_theme()`. I'm copying my comment from
 https://core.trac.wordpress.org/ticket/63062#comment:30 for visibility:
 >
 > > Digging deeper into the Core to understand the issue, I found that:
 > > * `wp_is_block_theme` doesn't need to be called after
 `after_theme_setup`, it just needs to be called after
 [https://github.com/WordPress/wordpress-
 develop/blob/32fe6af9c36e2b80e79a664fc6ae53d9c5cd3f9a/src/wp-
 settings.php#L519 theme directories registration].
 > > * The initial issue with the child theme is caused by calling that
 function after [https://github.com/WordPress/wordpress-
 develop/blob/32fe6af9c36e2b80e79a664fc6ae53d9c5cd3f9a/src/wp-
 settings.php#L514 creating post types], which is before the theme
 directories registration.
 > > * Moving that logic to `after_theme_setup`, as we did in this ticket,
 is enough to solve the issue.
 > > * Plugins can never break the theme resolution because they are loaded
 [https://github.com/WordPress/wordpress-
 develop/blob/32fe6af9c36e2b80e79a664fc6ae53d9c5cd3f9a/src/wp-
 settings.php#L529-L557 after] theme directories registration.
 > > So the warning and early return don't protect us from anything and
 should be removed.

 @dinhtungdu thank you for investigating further!

 Even though regularly loaded plugins can call `wp_is_block_theme()` before
 the themes are set up without causing the same bug that was reported in
 #63062, plugins loaded as mu-plugins would cause the bug to reappear. I
 was able to confirm this by creating a simple mu-plugin that called
 `wp_is_block_theme()` directly. Seems like we should still throw a warning
 of some sort so developers will know that they should not call this method
 too early.

 On further investigation, it's not the `WP_Theme::is_block_theme()` that
 causes the global `$wp_theme_directories` value to become corrupted, but
 it's actually the call to `wp_get_theme()` in `wp_is_block_theme()`, so
 the warning is indeed being added in the wrong place.

 We chose to add this warning on `setup_theme` so that the theme's
 themselves safely use the functions that rely on `wp_is_block_theme()`,
 during setup, but that any code trying to rely on checking on whether the
 current theme was a block theme was waiting for themes to be set up first.
 The intent of that placement still seems correct to me since I'm unsure
 why a plugin would want to call `wp_is_block_theme()` prior to the themes
 actually being set up.

 My suggestion is to move the warning from the `WP_Theme::is_block_theme()`
 to `wp_is_block_theme()` directly, and still keep the warning on the
 `setup_theme` hook. This may still result in warnings from plugins that
 are calling this code directly, but seems like the expectation should be
 that this function is not called until after themes are properly set up,
 otherwise, the plugin may return an incorrect value.

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