-
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
Unable to target group block with variation applied #41230
Comments
Generally, variations are pre-configured settings for a block and don't have a custom class attached to them. Would it make more sense for there to be justification and/or orientation-based classes that are more general purpose than specific to Group? However, there is some precedent for variations having their own classes, but these are also very specific cases:
|
A current use-case is to be able to adjust the block gap on row-layout group blocks; that's impossible in 6.0-RC4. Generic justification and orientation classes - even if they're not used by core to control layout - would be a simple and effective way to be able to target such blocks. |
If there are e.g. orientation classes, then this would allow them to be applied by core instead of outputting the rules over and over again as part of inline CSS. (See #36135 for a very similar topic, in which @keithdevon suggests a similar solution featuring reusable class names instead of repetitive inline rules.) |
Also related: Here is my workaround filter for now: function block_filter_group_add_layout_classes($block_content, $block)
{
if (empty($block["attrs"]["layout"])) {
return $block_content;
}
$classes = ["has-layout"];
if (!empty($block["attrs"]["layout"]["type"]) && $block["attrs"]["layout"]["type"] == "flex") {
$orientation = "horizontal"; // orientation not set on "row" variation as of 6.0, so assume row if absent
if (isset($block["attrs"]["layout"]["orientation"])) {
$orientation = $block["attrs"]["layout"]["orientation"];
}
switch ($orientation) {
case "vertical":
$classes[] = "is-stack";
break;
default:
$classes[] = "is-row";
break;
}
}
if (!empty($block["attrs"]["layout"]["justifyContent"])) {
$classes[] = "is-content-justification-" . $block["attrs"]["layout"]["justifyContent"];
}
if (!empty($block["attrs"]["layout"]["flexWrap"])) {
$classes[] = "is-" . $block["attrs"]["layout"]["flexWrap"];
}
if (!empty($classes)) {
$classes = implode(" ", $classes);
$search = 'class="wp-block-group';
$replace = 'class="wp-block-group ' . $classes;
$block_content = preg_replace("/" . $search . "/", $replace, $block_content, 1);
}
return $block_content;
}
add_filter("render_block_core/group", "block_filter_group_add_layout_classes", 10, 2); This is from a non-theme.json theme with the |
#38719 seems to be highly relevant. This has clarified that some semantic class names, which we're discussing here, have actually been removed at some point since 5.8. I expect that this was a decision made by someone, possibly erroneously, when moving CSS to the inline output. |
Thank you @cbirdsong for the suggestion; that had been the approach which I have as a draft in our basis theme. It seems somewhat counter-intuitive to re-build the code through the |
Closing this in favour of #38719, with a reference to #38719 (comment) for an example for an interim solution. |
Description
The new block variations for the group block generate inline CSS, but the lack of a CSS class name (e.g.
wp-block-group--stacked
orwp-block-group--row
) makes it impossible to target these elements using theme/plugin CSS.Step-by-step reproduction instructions
Apply a row or stack layout to the group block.
Screenshots, screen recording, code snippet
No response
Environment info
Please confirm that you have searched existing issues in the repo.
Yes
Please confirm that you have tested with all plugins deactivated except Gutenberg.
Yes
The text was updated successfully, but these errors were encountered: