Make WordPress Core

Opened 8 months ago

Closed 6 months ago

#54916 closed defect (bug) (fixed)

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

Reported by: rufus87's profile Rufus87 Owned by: audrasjb's profile audrasjb
Milestone: 5.9.3 Priority: normal
Severity: major Version: 5.9
Component: Administration Keywords: has-patch commit fixed-major
Focuses: Cc:

Description

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;

https://prnt.sc/26jh4es
https://prnt.sc/26jh4o3

Best regards

Attachments (3)

Capture d’écran 2022-03-29 à 17.20.00.png (383.7 KB) - added by audrasjb 6 months ago.
Using a classic theme: no change
Capture d’écran 2022-03-29 à 17.19.46.png (140.4 KB) - added by audrasjb 6 months ago.
Using a block theme without widget support: no change
Capture d’écran 2022-03-29 à 17.19.30.2.png (174.5 KB) - added by audrasjb 6 months ago.
Using a block theme which supports widgets: the menu is located at the last position

Download all attachments as: .zip

Change History (29)

#1 @SergeyBiryukov
8 months ago

  • Component changed from General to Administration
  • Milestone changed from Awaiting Review to 5.9.1

This ticket was mentioned in PR #2232 on WordPress/wordpress-develop by rufus87.


8 months ago

  • Keywords has-patch added

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

This ticket was mentioned in PR #2232 on WordPress/wordpress-develop by rufus87.


8 months ago

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

#4 @ironprogrammer
8 months ago

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.

#5 @Rufus87
8 months ago

Thanks @ironprogrammer !

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

Thanks.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


8 months ago

#7 @audrasjb
8 months ago

  • Keywords needs-testing added

#8 @ironprogrammer
8 months ago

  • Keywords needs-testing removed

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

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

https://cldup.com/-lgJ1adSdF.thumb.png

After Patch: Widgets menu follows Customize menu

https://cldup.com/MUNB6IrpU9.thumb.png

#9 @hellofromTonya
8 months ago

  • Keywords 2nd-opinion added
  • Milestone changed from 5.9.1 to 5.9.2

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.

#10 follow-up: @Rufus87
8 months ago

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.

#11 @ironprogrammer
8 months ago

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.

#12 in reply to: ↑ 10 @azouamauriac
7 months ago

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.

#13 @azouamauriac
7 months ago

#55282 was marked as a duplicate.

#14 @audrasjb
7 months ago

  • Milestone changed from 5.9.2 to 5.9.3

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

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


7 months ago

#16 @audrasjb
7 months ago

  • Keywords needs-patch added; has-patch removed
  • Owner set to audrasjb
  • Status changed from new to accepted

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.

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


6 months ago

This ticket was mentioned in PR #2475 on WordPress/wordpress-develop by audrasjb.


6 months ago

  • Keywords has-patch added; needs-patch removed

@audrasjb
6 months ago

Using a classic theme: no change

@audrasjb
6 months ago

Using a block theme without widget support: no change

@audrasjb
6 months ago

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

#19 @audrasjb
6 months ago

  • Keywords 2nd-opinion removed

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

This ticket was mentioned in Slack in #core by audrasjb. View the logs.


6 months ago

#21 @audrasjb
6 months ago

  • Keywords commit added

#22 @audrasjb
6 months ago

  • Resolution set to fixed
  • Status changed from accepted to closed

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.

#25 @audrasjb
6 months ago

  • Keywords fixed-major added
  • Resolution fixed deleted
  • Status changed from closed to reopened

Reopening for backport to branch 59

#26 @audrasjb
6 months ago

  • Resolution set to fixed
  • Status changed from reopened to closed

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.

Note: See TracTickets for help on using tickets.