-
Notifications
You must be signed in to change notification settings - Fork 4.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Load block support styles in the <head>
for block themes.
#38750
Changes from all commits
864cd6c
431c979
07d321a
8cbc00e
c3d70e1
37dcaa3
3ed7cd0
c43b935
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -590,3 +590,29 @@ function gutenberg_multiple_block_styles( $metadata ) { | |
return $metadata; | ||
} | ||
add_filter( 'block_type_metadata', 'gutenberg_multiple_block_styles' ); | ||
|
||
/** | ||
* This function takes care of adding inline styles | ||
* in the proper place, depending on the theme in use. | ||
* | ||
* For block themes, it's loaded in the head. | ||
* For classic ones, it's loaded in the body | ||
* because the wp_head action (and wp_enqueue_scripts) | ||
* happens before the render_block. | ||
* | ||
* See https://core.trac.wordpress.org/ticket/53494. | ||
* | ||
* @param string $style String containing the CSS styles to be added. | ||
*/ | ||
function gutenberg_enqueue_block_support( $style ) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
Can do that.
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. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. 3ed7cd0 consumers no longer need to provide the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. It would be nice to have a reserved block supports style handle. That doesn't output the Maybe it's something we can explore for 6.0.
youknowriad marked this conversation as resolved.
Show resolved
Hide resolved
|
||
$action_hook_name = 'wp_footer'; | ||
if ( wp_is_block_theme() ) { | ||
$action_hook_name = 'wp_enqueue_scripts'; | ||
} | ||
add_action( | ||
$action_hook_name, | ||
function () use ( $style ) { | ||
echo "<style>$style</style>\n"; | ||
} | ||
); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit pick: we can do $style =
".$class_name a{$link_color_declaration;}";
.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.