Load block support styles in the head for block themes #2323
Conversation
| } | ||
| add_action( | ||
| $action_hook_name, | ||
| function () use ( $style ) { |
There was a problem hiding this comment.
| function () use ( $style ) { | |
| static function () use ( $style ) { |
Tiny performance boost where PHP creates the embedded function once as a static instead of it being created each time the parent function is invoked.
| * | ||
| * @param string $style String containing the CSS styles to be added. | ||
| */ | ||
| function wp_enqueue_block_support( $style ) { |
There was a problem hiding this comment.
-
The function name does not fully identify what happens when this function is invoked. Its purpose is to enqueue styles rather than "support". How about
wp_enqueue_inline_block_styles? @oandregal what do you think? -
Let's move this function to
wp-includes/script-loader.phpwhere like functions exist. -
Nitpick:
@sinceannonation is needed (though can be added by core committer in prepping the commit.
There was a problem hiding this comment.
- Naming. I'd like to retain the
block_supportif possible, perhapswp_enqueue_block_support_styles? - Moving: I'm fine with that place if folks are opinionated about that. I also wanted to share more of the rationale as to why
blocks.phpsounds like a good place as well: this is where other functions related to blocks live, such aswp_enqueue_block_styleorwp_migrate_old_typography_shapethat deal with block things (styles, block supports, etc). - Sorry I've missed the
@sincetag.
| * because the wp_head action (and wp_enqueue_scripts) | ||
| * happens before the render_block. | ||
| * | ||
| * See https://core.trac.wordpress.org/ticket/53494. |
There was a problem hiding this comment.
This needs @since annotation
| } | ||
| add_action( | ||
| $action_hook_name, | ||
| function () use ( $style ) { |
There was a problem hiding this comment.
How can someone unhook this function if desired?
There was a problem hiding this comment.
This same problem exists elsewhere too. Here's the ticket for that work https://core.trac.wordpress.org/ticket/54028.
There was a problem hiding this comment.
It's also preexisting to this PR, note that this focused on fixing a bug with block themes (and moved this code around for convenience). I didn't have the context on why an anonymous function was used, so I didn't want to mix things. That can be updated separately.
| * because the wp_head action (and wp_enqueue_scripts) | ||
| * happens before the render_block. | ||
| * | ||
| * See https://core.trac.wordpress.org/ticket/53494. |
There was a problem hiding this comment.
| * See https://core.trac.wordpress.org/ticket/53494. | |
| * @link https://core.trac.wordpress.org/ticket/53494. |
|
@swissspidy @hellofromtonya I see this had already been approved&commited at https://core.trac.wordpress.org/changeset/52741 Is there anyone with commit access that can do those changes directly? I also can prepare a follow-up if it's convenient for people. |
|
@jorgefilipecosta is preparing a follow-up commit https://wordpress.slack.com/archives/C02RQBWTW/p1645035406929929 |
Part of https://core.trac.wordpress.org/ticket/55148
Backports WordPress/gutenberg#38750
The dynamic block styles for layout and elements should be loaded in the
<head>for block themes. While that should also be the case for classic themes, the current mechanism we use (render_block) does not allow us to do that, hence, this PR doesn't change anything for them and will be loaded the<body>.How to test
Block theme in WordPress 5.9:
.wp-elements-UUID ...) and layout (.wp-container-UUUID ...) are loaded in the<head>.Classic theme in WordPress 5.9:
.wp-elements-UUID ...) and layout (.wp-container-UUUID ...) are loaded in the<body>.