Generate element classnames from element-specific data

[tellthemachines]

What?

Fixes #59462.

Classname generation for block-specific element (e.g. link, heading) styles was dependent on the block array being identical between pre_render_block and render_block filters. That can't be assured, because between those two filters, the render_block_data filter also runs and the block array can be modified within it.

This PR updates the element classname hash generation to use only the style.elements array instead of the full block, because that is less likely to change between filters.

Testing Instructions

1. In a post or page, add a Group block with a Paragraph inside it.
2. Add a link to the Paragraph.
3. under the sidebar Color panel, add link color for both the Group and the Paragraph.
4. Check that the correct link color displays in both editor and front end (it should be the color added to the Paragraph, which overrides the one added to the Group.
5. Add a second Paragraph with a link inside the Group without setting its link color. Verify that it uses the Group link color.

Testing Instructions for Keyboard

Screenshots or screencast

[github-actions]

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @nitamorais.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: nitamorais.

Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org>
Co-authored-by: ramonjd <ramonopoly@git.wordpress.org>
Co-authored-by: andrewserong <andrewserong@git.wordpress.org>
Co-authored-by: aaronrobertshaw <aaronrobertshaw@git.wordpress.org>
Co-authored-by: huubl <huubl@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

[github-actions]

This pull request has changed or added PHP files. Please confirm whether these changes need to be synced to WordPress Core, and therefore featured in the next release of WordPress.

If so, it is recommended to create a new Trac ticket and submit a pull request to the WordPress Core Github repository soon after this pull request is merged.

If you're unsure, you can always ask for help in the #core-editor channel in WordPress Slack.

Thank you! ❤️

View changed files

❔ lib/block-supports/elements.php

[ramonjd]

Thanks for the quick fix!

Before

Here's my paragraph, with the green color for links:

And the frontend (shows purple group block link color)

After

Now the frontend shows the paragraph green link color:

[andrewserong]

+1, nice quick fix, this is testing well for me, too! ✨

[tellthemachines]

Thanks for reviewing, folks! Might be good to release 17.8.1 with this fix.

[andrewserong]

Might be good to release 17.8.1 with this fix.

Yes, that's a great idea 👍

[aaronrobertshaw]

Bit slow but this tests well for me and resolves the issue outlined in #59462.

We probably also need to update core so that the classname generation function doesn't appear to accept a full block object.

[tellthemachines]

I just cherry-picked this PR to the release/17.8 branch to get it included in the next release: d9c88be

[aaronrobertshaw]

@tellthemachines we still have a problem with the element link styles. The latest approach means we generate the same class for two blocks with the same style set. With nesting, this can break the correct inheritance of styles.

Screen.Recording.2024-03-04.at.10.41.48.am.mp4

[aaronrobertshaw]

The pre_render_block filter for the elements block support adds styles to the style engine store using the generated class name.

When the two blocks generate the same class name, the same CSS might be generated but there is only a single entry in the style engine store. It retains its original place in the order such that any subsequent blocks that had the matching style data won't have their own unique class and styles meaning they could be overridden incorrectly.

I think we still need a way to make these classes unique but predictable.

[tellthemachines]

Hm I suspect that's due to deduping of rules in the style engine. I guess an alternative approach would be to use render_block_data instead of pre_render_block for the CSS generation, and add the generated classname to the block array so that we don't need to re-generate and add it again in render_block.

[aaronrobertshaw]

add the generated classname to the block array so that we don't need to re-generate and add it again in render_block

I had similar thoughts. We'd probably need to go back to more than just the element styles to avoid the conflict in class name all the same.

[aaronrobertshaw]

I have a draft PR up (#59535) that aims to avoid the latest issue with element classes and styles.

[youknowriad]

I'm assuming this is not a 6.5 issue but just want to confirm.

[gaambo]

I originally reported #51082 where the link color style selector was wrong. I just confirmed via WordPress Playground that this PR fixes this issue. Thank you 🙏

[andrewserong]

I'm assuming this is not a 6.5 issue but just want to confirm.

Yes, I believe this isn't required for 6.5. While the underlying issue was reported last year (#51082), it was recently exposed via updates to the layout block support that are for 6.6.