Fix: Block pseudo-state styles incorrectly applied to default state

[MaggieCabrera]

Backport for WordPress/gutenberg#76326
Core trac ticket: https://core.trac.wordpress.org/ticket/64838

What?

When a block defines a custom feature selector in its block.json (e.g. core/button uses .wp-block-button for writingMode rather than the root .wp-block-button .wp-block-button__link), styles set on a pseudo-state like :hover via theme.json were being output under the default-state selector instead of the pseudo-state selector.

Why?

This bug will become more apparent when there's a UI to change the state of the button block after WordPress/gutenberg#75627 lands.

How?

In get_block_nodes, the metadata node for a block pseudo-state was built with the original $feature_selectors (e.g. .wp-block-button) rather than the pseudo-scoped version (e.g. .wp-block-button:hover). The fix builds a $pseudo_feature_selectors array that appends the pseudo-selector to every feature selector string before the node is created.

We have added a test to catch this problem should there be a regression

Testing Instructions

Add writing mode to a button block on hover on theme.json, check the frontend and you will see the CSS generated:

Before:
:root :where(.wp-block-button) { writing-mode: vertical-rl; }

After:
:root :where(.wp-block-button:hover) { writing-mode: vertical-rl; }

The unit tests should all pass too

[github-actions]

Test using WordPress Playground

The changes in this pull request can previewed and tested using a WordPress Playground instance.

WordPress Playground is an experimental project that creates a full WordPress instance entirely within the browser.

Some things to be aware of

• All changes will be lost when closing a tab with a Playground instance.
• All changes will be lost when refreshing the page.
• A fresh instance is created each time the link below is clicked.
• Every time this pull request is updated, a new ZIP file containing all changes is created. If changes are not reflected in the Playground instance,
  it's possible that the most recent build failed, or has not completed. Check the list of workflow runs to be sure.

For more details about these limitations and more, check out the Limitations page in the WordPress Playground documentation.

Test this pull request with WordPress Playground.

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

Core Committers: Use this line as a base for the props when committing in SVN:

Props onemaggie, isabel_brison.

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

[MaggieCabrera]

Closing since the changes are covered by #12253 and #11706

[MaggieCabrera]

On second though I'll reopen this because the backport is already registered to this ticket and it's worth it keeping the test in and not all code changes were included in the previous backports

[MaggieCabrera]

/cc @tellthemachines if you could have a look?

[tellthemachines]

The issue is fixed on trunk but yeah we should delete the dead code and may as well add the test!

[github-actions]

A commit was made that fixes the Trac ticket referenced in the description of this pull request.

SVN changeset: 62639
GitHub commit: 64ede28

This PR will be closed, but please confirm the accuracy of this and reopen if there is more work to be done.

[MaggieCabrera]

@tellthemachines thank you kindly