Allow blocks to use the role attribute #47868
Open
+154
−1
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
carolinan
added
[Block] Buttons
|
Size Change: +98 B (0%) Total Size: 1.7 MB
ℹ️ View Unchanged
|
carolinan
requested review from
ellatrix,
ajitbohra,
ajlende,
ryanwelcher,
juanmaguitar and
fabiankaegy
as code owners
|
Flaky tests detected in be52745. 🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/6312579752
|
|
@carolinan Just noting that your example should probably read like this. Old: New: Adding Thanks. |
gziolo
added
[Feature] Block API
|
@gziolo I have not been able to add the role attribute to the link in the button block. The filter for the save, |
As far as I'm aware, blocks that want to avoid injecting the value from the feature/attribute in the root element use |
gziolo
removed
[Feature] Block API
carolinan
changed the title
|
I apologize for all the back and forward. To summarize:
|
carolinan
commented
Mar 2, 2023
|
How do I test it with dynamic blocks? |
|
@carolinan Yeah exactly like that :) |
|
And from there if this attribute is present and the block has the block support for it, the This is how it was done for the gutenberg/lib/block-supports/anchor.php Lines 30 to 67 in 27b1f79 Which will mean that a patch in WordPress Core is also needed to allow the |
carolinan
changed the title
|
Thanks for working on this, @carolinan! Maybe we should avoid using a general solution here and use a more direct approach by adding a WhyCurrently, there're only two use cases in the core, and not every block can apply a The latter means that consumers have to handle applying the I think block support-based global enhancements are more useful when they unlock UI, so developers don't have to implement it. Developer-oriented features like this and P.S. We should probably avoid introducing server-side support until |
|
It does need a core change, but I did not create that ticket since it would be unnecessary if this feature would not be considered. |
|
I could add it as an attribute to the group, as this block has the greatest versatility, where many different roles would be suitable in different situations. It would also mean that any custom blocks would need to each make their own implementation instead of using the built-in support? |
I think that would be an excellent first step. Then we can evaluate feedback/usage, introduce the We're already taking a similar approach with It would have been preferable for |
|
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/role.php ❔ lib/load.php |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
What?
This PR:
roleblock support that allows developers to add aroleattribute in the markup without causing block validation errors.Closes #46002
Why?
Allowing the role attribute increases the flexibility for theme and plugin authors. It compliments the HTML element selection option that is in the Advanced panel for supported blocks.
Testing Instructions
In your WordPress install, locate wp-includes/class-wp-block-supports.php.
On line 184, inside function
get_block_wrapper_attributes,add
roleto the array of attributes:$attributes_to_merge = array( 'style', 'class', 'id', 'role' );Next, login to your WordPress install and create a new post.
Add a group block with a list of links inside.
Open the code editor mode.
Add "role":"navigation" in the block comment.
Add
role="navigation"to the div:Save and exit code editor mode.
Confirm that there are no block validation errors.
View source; confirm that the role on the group block is still
role="document"View the post on the front, confirm that the role attribute is present.
This should be tested with and work with themes with and without theme.json.
To test with a dynamic block:
Locate and open the block.json file for a dynamic block, for example the avatar, latest posts or post featured image.
Add
"role":trueto the list of block supports.Build the Gutenberg plugin to apply the change.
Add the block in the block editor.
Open the code editor mode and add the role to the block comment (see example above).
Save and confirm that there are no block validation errors.
View the block on the front and confirm that the role attribute is added correctly.
(Don't forget to revert the change you made to the WordPress file when you are done testing :) )