CSS link color specified in templates not generated in v17.8.0

[huubl]

Description

In Gutenberg v17.8.0, the link color specified in the template is not being applied to the link when viewed in the frontend. It seems that the style rules are not correctly generated.

Step-by-step reproduction instructions

1. Open WP playground with Gutenberg 17.8.0 installed and activated
2. Navigate to the Site Editor and edit a template.
3. Create a paragraph block with a link. Add a link color using the color settings or copy and paste the following code into the code editor:

<!-- wp:paragraph {"align":"center","style":{"elements":{"link":{"color":{"text":"var:preset|color|accent-3"}}}},"textColor":"accent-3"} -->
<p class="has-text-align-center has-accent-3-color has-text-color has-link-color">Études is a pioneering firm<a href="#link-color-is-missing">that seamlessly</a> merges creativity and functionality to redefine architectural excellence.</p>
<!-- /wp:paragraph -->

4. Save and preview the page in the frontend.
5. Observe that the color specified for the link is not applied.

Screenshots, screen recording, code snippet

Environment info

• Wordpress version 6.4.3
• Gutenberg version 17.8.0

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

[linwoodlana]

Same here. When changing a link color, for instance in post title query it only applies in editor but in frontend the browser uses its default link colors.
Only in global styles/color/link it works but of course for all links!

[aaronrobertshaw]

I can replicate the issue on trunk within the post editor, separate to templates as well.

Replication steps are the same:

1. In post editor, add a paragraph
2. Create a link within the paragraph
3. Select the paragraph and apply link color via block inspector
4. Save and view on the frontend

[aaronrobertshaw]

It appears as though something has changed with regard to the generation of the wp-elements class name. The same call to the wp_get_elements_class_name function is returning different classes for the two hooks that apply the block instance element styles.

function wp_get_elements_class_name( $block ) {
	return 'wp-elements-' . md5( serialize( $block ) );
}

As the class name includes a hash of the $block, my guess is there's another filter changing the block data between the pre_render_block and render_block filters.

[aaronrobertshaw]

The root cause of this issue occurs when the parentLayout attribute is added to the block via the render_block_data filter. This changes the class name generated across the two filters the elements block support uses, one to inject the class into the block content markup, and the second to generate the CSS for the element styles.

The elements block support needs the combination of the two filters. The pre_render_block filter is used so the order of the element styles supports nesting and the correct cascade of styles is achieved. The class name can't be added to the markup in that same filter.

The changes regarding the parentLayout attribute look like they were introduced via #59057.

[tellthemachines]

Hmm, I think the best way forward is to change the approach to element classname generation so it's not dependent on mutable data. The render_block_data filter is a public API; there's no way of controlling what it gets used for.