Heading: Enable heading level curation #63535
Merged
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
ndiego
added
[Type] Enhancement
ndiego
requested review from
ajitbohra,
ryanwelcher,
juanmaguitar and
fabiankaegy
as code owners
|
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 If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message. To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook. |
|
Size Change: +18 B (0%) Total Size: 1.75 MB
ℹ️ View Unchanged
|
|
Please review this needed issue. |
|
I see 6 blocks using the "level" attribute. Do we want to be consistent and add this attribute to all the blocks. Personally, I'm fine with the proposed approach here, especially as changing the default value of this particular attribute doesn't invalidate the block. It's also a very similar approach to what we did before for things like "allowedBlocks". |
Yeah, that was my thought, but I wanted to use the Heading block as a proof of concept. Happy to tackle the remaining blocks if we all like this approach. |
|
What are the other blocks using |
These are the blocks with the
|
youknowriad
approved these changes
Jul 29, 2024
fabiankaegy
added
the
Needs Dev Note
ndiego
added
the
props-bot
ndiego
removed
the
props-bot
This was referenced Jul 30, 2024
This was referenced Jul 30, 2024
97 tasks
|
Dev note: Heading level curation in WordPress 6.7In WordPress 6.7, core blocks with a heading level dropdown now support the new This attribute allows developers to specify which heading levels should appear in the dropdown UI, providing a lightweight curation method that does not require block deprecations. Any existing heading levels are preserved in the markup, while You can apply this attribute directly in the block markup, a technique that will be commonly used in block templates, template parts, and patterns. For example, the following markup disables H1, H2, and H6 in the Heading block by setting You can also use block filters to set the default value of this attribute globally or for specific blocks. The example below disables H1, H2, and H6 for all Heading blocks. You can further customize this by restricting certain heading levels based on conditions like user capabilities. When either of the two examples above are applied, the Heading block UI in the Editor will look like this.
cc @fabiankaegy, do you want me to draft this as its own dev note on Make, or do you think this will be part of a larger note? |
|
@ndiego I think it makes more sense to have this as part of the larger Miscellaneous Editor Changed Dev note. Not a strong opinion though if you think it deserves its own. |
Sounds good to me. Let me know if you need anything else from me for the note. |
|
@ndiego From my first review it looks perfect :) I'll let @mumtahinafaguni chime in with feedback also but on first glance it is all we need :) Thank you as always! ❤️ |
|
Spotted a small typo in the dev note draft: |
|
Thanks @afercia, fixed! |
|
How change the default value of heading, for exemple change to h3 |
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.
Fixes #63527, #20213
What?
This PR is a minimalistic attempt to solve the longstanding issue that you cannot modify the available heading levels provided by the Heading block. This block is powered by the HeadingLevelDropdown component. This component accepts an
optionsparameter that allows you to choose which levels are available in the dropdown. Unfortunately, there is no way to modify thisoptionsparameter from a Heading block.This PR adds a
levelOptionsparameter to the Heading block to resolve this.Why?
Being able to restrict the available heading levels is crucial in many situations, whether it be general Editor curation, accessibility, block governance, SEO, etc.
How?
This PR adds a
levelOptionsparameter to the Heading block that allows developers to define which heading levels should be displayed in the Heading dropdown UI. The approach is very simple and does not require a depreciation. Any previously set heading levels are respected in the markup. This attribute just allows you to control the UI. I could see how we may want to extend this future in the future, but the goal with this PR is to keep things simple and solve an immediate need of the community. Implementing this attribute does not block/preclude additional enhancements in the future.I chose the name
levelOptionsbecause we are already using thelevelattribute in the block, and the parameter in theHeadingLevelDropdowncomponent isoptions.If we like this approach, follow-up PRs should be created to add similar functionality to all blocks that use the
HeadingLevelDropdown.With this new attribute, you can restrict the UI in many different ways, making this approach very flexible and powerful. For example, you could restrict options directly in block markup for a pattern or template. Try copying and pasting the following in the Editor.
Or you could modify the attribute programmatically via filters. The following will disable
h1globally. You could also add conditionals for post type, user permissions, etc. There are filters for both PHP and JavaScript so the applications are endless.Testing Instructions
functions.phpfile of your theme and see thath1is disabled.Screenshots or screencast
cc @ryanwelcher @troychaplin @amberhinds since we chatted about this at WordCamp Canada. 🇨🇦
cc @carolinan @fabiankaegy @richtabor @jasmussen for additional code/design feedback 🙏