[wp-trac] [WordPress Trac] #56467: Update @wordpress packages and backport changes from Gutenberg plugin into Core

[WordPress Trac]

#56467: Update @wordpress packages and backport changes from Gutenberg plugin into
Core
-------------------------------------------------+-------------------------
 Reporter:  Bernhard Reiter                      |       Owner:  Bernhard
                                                 |  Reiter
     Type:  task (blessed)                       |      Status:  closed
 Priority:  normal                               |   Milestone:  6.1
Component:  Editor                               |     Version:
 Severity:  normal                               |  Resolution:  fixed
 Keywords:  has-patch has-unit-tests fixed-      |     Focuses:
  major                                          |
-------------------------------------------------+-------------------------

Comment (by flixos90):

 Replying to [comment:411 scruffian]:
 > > I would think this logic is pointless to run for classic themes
 without a theme.json
 >
 > One of the changes introduced in 6.1 is that some blocks now load their
 styles using the __experimentalStyles property in their block.json, as
 well as from their CSS file. Given that blocks and their styles are loaded
 for both classic and block themes, it is necessary for us to output these
 rules into CSS in both types of themes. Hope that makes sense!

 Thanks for clarifying, that makes sense. However, if for classic themes
 this is only needed to add those block styles, why are we running all the
 other logic that is invoked by `wp_add_global_styles_for_blocks()`? I took
 a bit of time to dive into the `WP_Theme_JSON_Resolver` code, and it does
 a whole lot of things that appear to only relate to FSE themes without any
 checks for `theme_has_support()`.

 For example:
 * `wp_add_global_styles_for_blocks()` calls
 `WP_Theme_JSON_Resolver::get_merged_data()`.
 * From there, it calls `get_core_data()`, `get_block_data()`,
 `get_theme_data()`, and `get_user_data()`. Based on what you're saying,
 for a classic theme it would make more sense to only call
 `get_block_data()`, not the other 3.
 * By doing that, we would avoid several expensive actions which seem
 unnecessary for classic themes:
     * Read, parse, and translate, WP core's own `theme.json`
     * Load the translation schema even though the theme has no
 `theme.json`
     * Run a database query to get global styles

 Of the above points, the only thing that changes anything in the relevant
 data is not parsing core's `theme.json`. However, the data in that is not
 really used for classic themes anyways, so that should also be fine.

 I've done a first test, and it appears that removing these calls does not
 result in any missing functionality for classic themes. You can see this
 issue first-hand in action with Twenty Twenty-One:
 1. Set up a site with Twenty Twenty-One.
 2. Modify `WP_Theme_JSON_Resolver::get_core_data()` to just set `$config`
 to an empty array instead of parsing core's `theme.json`.
 3. Modify `WP_Theme_JSON::set_spacing_sizes()` to include an `! isset(
 $spacing_scale['steps'] )` check, since that key may not be present now,
 to avoid a PHP warning.
 4. Inspect the frontend of the site before and after the change. There is
 no change in any of the CSS included, except that a single CSS rule
 `:where(.wp-block-columns.is-layout-flex){gap: 2em;}` is now gone. To be
 fair, I'm a bit unclear why that was there in the first place, since the
 `is-layout-flex` class is not used anywhere on the page.

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