Load block support styles in the <head> for block themes.
#38750
Conversation
oandregal
requested review from
TimothyBJacobs and
spacedmonkey
as code owners
oandregal
added
[Type] Bug
oandregal
added
the
Backport to WP Minor Release
|
This is working for block themes but it isn't for classic ones. Need to investigate further. |
|
This is now working. I've updated the issue description to better reflect what this does: the block themes always have the block supports styles in the head and the classic ones in the body. |
| * | ||
| * @param string $style HTML content to load in the <head> or <body>. | ||
| */ | ||
| function gutenberg_enqueue_block_support( $style ) { |
There was a problem hiding this comment.
The function wp_add_inline_style, which is similar receives a styles string and outputs it and it receives the styles without "style" tag so I guess this function should also not include the style tag.
On another question would it make sense to use wp_add_inline_style in this function instead of wp_enqueue_scripts? So for example a plugin can remove our styles etc...
There was a problem hiding this comment.
The function wp_add_inline_style, which is similar receives a styles string and outputs it and it receives the styles without "style" tag so I guess this function should also not include the style tag.
Can do that.
On another question would it make sense to use wp_add_inline_style in this function instead of wp_enqueue_scripts? So for example a plugin can remove our styles etc...
I'm on the fence here. My first instinct is to do not change how this works because I don't know why we made it this way in the first place. This PR just fixes the issue with block themes enqueuing the block supports in the body when they should use the head.
There was a problem hiding this comment.
3ed7cd0 consumers no longer need to provide the <style> tag.
There was a problem hiding this comment.
It would be nice to have a reserved block supports style handle. That doesn't output the link element but can be used for inline styles.
Maybe it's something we can explore for 6.0.
| @@ -43,7 +43,7 @@ function gutenberg_render_elements_support( $block_content, $block ) { | |||
| } | |||
| $link_color_declaration = esc_html( safecss_filter_attr( "color: $link_color" ) ); | |||
|
|
|||
| $style = "<style>.$class_name a{" . $link_color_declaration . ";}</style>\n"; | |||
| $style = ".$class_name a{" . $link_color_declaration . ';}'; | |||
There was a problem hiding this comment.
Nit pick: we can do $style = ".$class_name a{$link_color_declaration;}";.
There was a problem hiding this comment.
Nah, that's a syntax error (having a ; next to a variable $link_color_declaration). Note that the existing string concatenation also has it in separate strings for the same reason.
|
This is ready so I've gone ahead and prepared WordPress/wordpress-develop#2323 to backport it to WordPress develop. |
oandregal
changed the title
Mamaduka
removed
the
Backport to WP Minor Release
cbravobernal
changed the title
<head> for block themes.
|
@oandregal and @jorgefilipecosta, I believe I have found an issue with this implementation. In testing 12.7, the styles are now added near the top of
|
Part of #38434
Related #38745
Follow-up to #32083
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>.