👋 Thanks for your first Pull Request and for helping build the future of Gutenberg and WordPress, @mtias! In case you missed it, we'd love to have you join us in our Slack community.

If you want to learn more about WordPress development in general, check out the Core Handbook full of helpful information.

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.

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

Co-authored-by: mtias <matveb@git.wordpress.org>
Co-authored-by: youknowriad <youknowriad@git.wordpress.org>
Co-authored-by: Mamaduka <mamaduka@git.wordpress.org>
Co-authored-by: jasmussen <joen@git.wordpress.org>
Co-authored-by: fabiankaegy <fabiankaegy@git.wordpress.org>
Co-authored-by: ockham <bernhard-reiter@git.wordpress.org>
Co-authored-by: skorasaurus <skorasaurus@git.wordpress.org>
Co-authored-by: SaxonF <saxonafletcher@git.wordpress.org>
Co-authored-by: ndiego <ndiego@git.wordpress.org>
Co-authored-by: priethor <priethor@git.wordpress.org>
Co-authored-by: bgardner <bgardner@git.wordpress.org>
Co-authored-by: richtabor <richtabor@git.wordpress.org>

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

Size Change: +1.45 kB (+0.06%)

Total Size: 2.58 MB

_{compressed-size-action}

I've simplified the handling of levels so that the UI is entirely driven by variations, which means remove the specific levels dropdown and consolidation the toolbar.

I've simplified the handling of levels so that the UI is entirely driven by variations, which means remove the specific levels dropdown and consolidation the toolbar.

I in theory like the simplicity of this. But I think the UI change will be confusing.

It also creates a different experience than we show in the accordion block for example.

And finally I'm concerned of what this will mean for other variations such as the stretchy text. Can you not have a h4 stretchy text now?

@fabiankaegy what do you think will be confusing? It largely implements #55067.

The stretchy text stuff is moving to a block support, it should not be polluting the variations space. I think the current state creates awkwardness like #73819.

@mtias I think just the change in existing habits will create friction. Which is totally fine if we think it is worth it.

I'm more concerned about hiding the level dropdown entirely in favor of just variations.

If there are already existing other variations in plugins etc it just breaks those because they can now no longer change the heading level.

And I do think the fact that we use the heading level dropdown in multiple blocks already makes it odd to remove it from the heading. Lots of 3rd party blocks also use the HeadingLevelDropdown control.

Looks like some e2e tests need adjusting, e.g.

diff --git a/test/e2e/specs/editor/blocks/heading.spec.js b/test/e2e/specs/editor/blocks/heading.spec.js
index b27c0fa52e4..719694b2210 100644
--- a/test/e2e/specs/editor/blocks/heading.spec.js
+++ b/test/e2e/specs/editor/blocks/heading.spec.js
@@ -366,7 +366,7 @@ test.describe( 'Heading', () => {
                await expect(
                        headingListViewItem,
                        'should show default block name if the content is empty'
-               ).toHaveText( 'Heading' );
+               ).toHaveText( 'Heading 2' );
 
                await editor.canvas
                        .getByRole( 'document', {

relatedly to what @fabiankaegy stated; in my organization, we remove the heading level 1 for our content editors since all of our templates are locked and let our content editors just use 2-6.

So, currently, we have:

add_filter( 'register_block_type_args', 'restrict_heading_levels', 10, 2 );

function restrict_heading_levels( $args, $block_type ) {
	if ( 'core/heading' !== $block_type ) {
		return $args;
	}
	// do not include H1
	$args['attributes']['levelOptions']['default'] = [ 2, 3, 4, 5, 6 ];

	return $args;

That filter is no longer applicable with the proposed PR and will certainly deserve a devnote at the very least to inform developers of the change.

although I can confirm that unregistering the variation prevents the variation from appearing (like the following for level 1):

wp.blocks.unregisterBlockVariation( 'core/heading', 'h1' );

I am personally ambivalent about the change overall and understand its benefits.

The block's toolbar has inconsistently been used for setting some really core settings to a block in some cases (like whether or not the list is ordered or not) but not for others (group block, whether it's stack or row or grid), so this isn't any different.

@skorasaurus thanks for the example! Pushed some code to handle that directly. Unregistering the variation should be the more idiomatic way, but we can still keep support for the attribute filtering. Could you check that with the above your code still works?

@skorasaurus thanks for the example! Pushed some code to handle that directly. Unregistering the variation should be the more idiomatic way, but we can still keep support for the attribute filtering. Could you check that with the above your code still works?

Yes, I can confirm that with the newer build from e6a6074 ; just having my current code example alone removes H1 from appearing. Thanks for the adjustment.

@skorasaurus thanks for the example! Pushed some code to handle that directly. Unregistering the variation should be the more idiomatic way, but we can still keep support for the attribute filtering. Could you check that with the above your code still works?

Just putting it out there, but looking at #63535 I believe one of the "strengths" of that API over the unregistering of Variations is that it was context aware and instance based where as variations are global.

So with the olde model you were able to change the available heading levels on a per instance basis. Which this here doesn't allow for.

Flaky tests detected in 82b3673.
Some tests passed with failed attempts. The failures may not be related to this commit but are still reported for visibility. See the documentation for more information.

🔍 Workflow run URL: https://github.com/WordPress/gutenberg/actions/runs/20142548400
📝 Reported issues:

• [Flaky Test] should paginate #69568 in /test/e2e/specs/site-editor/user-global-styles-revisions.spec.js

@mtias Just a reminder, please make sure to copy the list of contributor props from the Props Bot comment on a given PR into the bottom of the commit message so that everyone is credited for their contributions.

In this case, everyone who participated is an established, frequent contributor. So they will be included in the next release's props anyway and it's not an issue. But it becomes difficult to track while preparing for a release when they are one-off contributions. Thank you and everyone here for contributing! ❤️

I realized after merging, was going to follow up with another commit. In my defense, it's my first pull request on this project!