Admin panel's "Customizer" sub menu is replaced with "Widgets" for block based themes

[Rufus87]

Hi there,

In the last 5.9 version there is an issue related to admin panel's "Customize" sub-menu item for block based themes. The problem is that for block based themes the "Customize" sub-menu item position is 7 (for the old themes it is 6). However, "Widgets" sub-menu item is constantly registered in the exactly same 7th position and in case of block based themes, it overwrites "Customize" sub-menu item.

The possible fix is to add the same condition check during "Widgets" sub-menu item registration, but increase position by 1:

wp_is_block_theme() ? 8 : 7;

Best regards

In the last 5.9 version there is an issue related to admin panel's "Customize" sub-menu item for block based themes. The problem is that for block based themes the "Customize" sub-menu item position is 7 (for the old themes it is 6). However, "Widgets" sub-menu item is constantly registered in the exactly same 7th position and in case of block based themes, it overwrites "Customize" sub-menu item.

I've added a small tweak that will increase "Widgets" sub-menu item position by 1 ( will be 8 instead of 7 ) by checking if active theme is a block based one ( using native "wp_is_block_theme" function )

Trac ticket: https://core.trac.wordpress.org/ticket/54916

In the last 5.9 version there is an issue related to admin panel's "Customize" sub-menu item for block based themes. The problem is that for block based themes the "Customize" sub-menu item position is 7 (for the old themes it is 6). However, "Widgets" sub-menu item is constantly registered in the exactly same 7th position and in case of block based themes, it overwrites "Customize" sub-menu item.

I've added a small tweak that will increase "Widgets" sub-menu item position by 1 ( will be 8 instead of 7 ) by checking if active theme is a block based one ( using native "wp_is_block_theme" function )

Trac ticket: https://core.trac.wordpress.org/ticket/54916

[ironprogrammer]

Thanks, @rufus87!

Testing

I am able to replicate this issue given the following conditions:

• WordPress version is 5.9.
• Active theme is a registered block theme.
• Theme registers widget support: add_theme_support( 'widgets' ).
• Theme hooks the customize_register action.

Patch

Please check the patch against ​WordPress's PHP coding standards or a utility like phpcs, which should help resolve the errors on the PR's merge check.

Notes

Menu item position 8 is not "reserved" for any other menu item, so this shift does not interfere with other built-in menu items. As such, the check for wp_is_block_theme may not be strictly necessary in this case.

[Rufus87]

Thanks @ironprogrammer !

I followed your advice and simply changed position "7" to "8".

Thanks.

[ironprogrammer]

I've tested ​PR 2232 and it looks good. Thanks, @Rufus87!

Before Patch: Widgets menu overrides (replaces) Customize menu position

After Patch: Widgets menu follows Customize menu

[hellofromTonya]

In reviewing the proposed solution of changing the Widget's position from 7 to 8, I wonder: What will the impact be to extenders who expect that menu item to be at position 7 (as it's always been)? Moving it may cause a new issue for them.

I'm moving this ticket to 5.9.2 for further consideration.

[Rufus87]

My first suggestion was to change Widget's position from 7 to 8 conditionally - using the same condition as Customizer for block based themes. I believe that it is the most acceptable solution for this issue.

[ironprogrammer]

Another option could be to remove the static position of that menu item. It would then fall in place where it currently is in a classic theme, or be "pushed down" by any extenders who are attempting to prioritize new menu items or set an explicit order.

Worst case in this scenario is that "Widgets" doesn't appear in an exact slot. But the benefit is that it would no longer be subject to being overwritten due to specific indexes.

[azouamauriac]

Replying to Rufus87:

My first suggestion was to change Widget's position from 7 to 8 conditionally - using the same condition as Customizer for block based themes. I believe that it is the most acceptable solution for this issue.

I agree with that too.

[azouamauriac]

#55282 was marked as a duplicate.

[audrasjb]

Moving to milestone 5.9.3 since we're about to release 5.9.2.

[audrasjb]

As from @hellofromtonya’s comment in the existing PR, moving the widget position from 7 to 8 will probably introduce other regressions, so it’s better to try to find another option, something doable for a point release.

I’d suggest to go with @ironprogrammer’s proposal:

Another option could be to remove the static position of that menu item. It would then fall in place where it currently is in a classic theme, or be “pushed down” by any extenders who are attempting to prioritize new menu items or set an explicit order. Worst case in this scenario is that “Widgets” doesn’t appear in an exact slot. But the benefit is that it would no longer be subject to being overwritten due to specific indexes.

…and we can still use a wp_is_block_theme() check to make sure this is only applied to block based themes.

Trac ticket: https://core.trac.wordpress.org/ticket/54916

[audrasjb]

Using a classic theme: no change

[audrasjb]

Using a block theme without widget support: no change

[audrasjb]

Using a block theme which supports widgets: the menu is located at the last position

[audrasjb]

As everyone was comfortable with this proposal during the last bug scrub(s), I'd suggest to go with this solution.

[audrasjb]

In 53020:

Administration: Do not specify menu order for the Widgets menu when the active theme is a block theme.

When using a block theme that declares Widgets support, it's better to not specify a menu order for the Widgets menu to avoid conflicts between menu items order.

Props Rufus87, ironprogrammer, audrasjb, hellofromTonya, davidbaumwald.
Fixes #54916.

Committed in https://core.trac.wordpress.org/changeset/53020

Committed in https://core.trac.wordpress.org/changeset/53020

[audrasjb]

Reopening for backport to branch 59

[audrasjb]

In 53021:

Administration: Do not specify menu order for the Widgets menu when the active theme is a block theme.

When using a block theme that declares Widgets support, it's better to not specify a menu order for the Widgets menu to avoid conflicts between menu items order.

Props Rufus87, ironprogrammer, audrasjb, hellofromTonya, davidbaumwald.
Merges [53020] to the 5.9 branch.
Fixes #54916.