Skip to content
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

Closed
markhowellsmead opened this issue May 23, 2022 · 7 comments
Closed

Unable to target group block with variation applied #41230

markhowellsmead opened this issue May 23, 2022 · 7 comments
Labels
[Block] Group Affects the Group Block (and row, stack and grid variants) [Feature] Block Variations Block variations, including introducing new variations and variations as a feature [Type] Enhancement A suggestion for improvement.

Comments

@markhowellsmead
Copy link

markhowellsmead commented May 23, 2022

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 or wp-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

  • WordPress 6.0-RC4
  • With and without Gutenberg plugin

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

@justintadlock justintadlock added [Type] Enhancement A suggestion for improvement. [Block] Group Affects the Group Block (and row, stack and grid variants) [Feature] Block Variations Block variations, including introducing new variations and variations as a feature labels May 23, 2022
@justintadlock
Copy link
Contributor

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:

  • Social Links - adds .wp-social-link-{slug}
  • Embeds - adds .is-provider-{slug} (front-end only)

@markhowellsmead
Copy link
Author

markhowellsmead commented May 23, 2022

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.

@markhowellsmead
Copy link
Author

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.)

@cbirdsong
Copy link

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 wp-container class output disabled, so I don't know how this interacts with that or custom units.

@markhowellsmead
Copy link
Author

markhowellsmead commented May 23, 2022

#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.

@markhowellsmead
Copy link
Author

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 render_block hook without first knowing what the reasons were behind the removal of the semantic class names in the first place.

@markhowellsmead
Copy link
Author

Closing this in favour of #38719, with a reference to #38719 (comment) for an example for an interim solution.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
[Block] Group Affects the Group Block (and row, stack and grid variants) [Feature] Block Variations Block variations, including introducing new variations and variations as a feature [Type] Enhancement A suggestion for improvement.
Projects
None yet
Development

No branches or pull requests

3 participants