PHP notice while accessing Customizer

[Boniu91]

Env

• WordPress 5.9
• Chrome 97.0.4692.71
• Windows 10
• Theme: Twenty Twenty Two
• Plugin: WooCommerce

Steps to reproduce

1. Open Appearance > Customizer
2. Check the debug log

[25-Jan-2022 20:15:07 UTC] PHP Notice:  Trying to get property 'title' of non-object in /var/www/domain.ovh/htdocs/wp-includes/class-wp-customize-nav-menus.php on line 523
[25-Jan-2022 20:15:07 UTC] PHP Notice:  Trying to get property 'title' of non-object in /var/www/domain.ovh/htdocs/wp-includes/class-wp-customize-nav-menus.php on line 1152

[jamieblomerus]

Have the same problem with 5.9 sometimes, but not always.

[pbiron]

line 523 is just trying to enqueue uneeded JS and line 1153 is trying to output some HTML that doesn't appear on screen because the Nav Menus panel doesn't.

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

hi thanks for the patch, tested and it works on my side, just one thought:

on line 1158, I think the if controle should wrap the span node too, to avoid orphan node ​https://prnt.sc/26tbhbx . thanks.

[SergeyBiryukov]

#55111 was marked as a duplicate.

[SergeyBiryukov]

#55171 was marked as a duplicate.

[hellofromTonya]

As discussions are continuing in the PR, moving this ticket to 5.9.2 to give time to resolve.

[rafiahmedd]

@Boniu91 couldn't reproduce the same issue in my environment. Which version of PHP you are running?

[ironprogrammer]

I was able to reproduce the issue. tl;dr, the patch fixes the original notices, but there is a strikingly similar notice now caused by class-wp-customize-widgets.php. @costdev, would you be able to address the same issue there in your PR?

Test Report

​PR 2227

Env

• WordPress 6.0-alpha-52448-src
• Safari 15.3
• macOS 12.2.1 (Monterey)
• Theme: Twenty Twenty-Two
• Gutenberg DISABLED 🔴
• Plugin: WooCommerce (activated, but not configured)
• wp-config: define( 'WP_DEBUG_LOG', true );

Steps to Test (BEFORE PATCH)

1. Navigate to Appearance > Customize (menu enabled by WooCommerce).
2. Observe that /wp-content/debug.log contains the following PHP notices (paths modified for privacy):

   [25-Feb-2022 17:53:11 UTC] PHP Notice:  Trying to get property 'title' of non-object in [...]/wp-includes/class-wp-customize-nav-menus.php on line 523
   [25-Feb-2022 17:53:12 UTC] PHP Notice:  Trying to get property 'title' of non-object in [...]/wp-includes/class-wp-customize-widgets.php on line 895
   [25-Feb-2022 17:53:12 UTC] PHP Notice:  Trying to get property 'title' of non-object in [...]/wp-includes/class-wp-customize-nav-menus.php on line 1152
   

Steps to Test (AFTER PATCH )

1. Navigate to Appearance > Customize (menu enabled by WooCommerce).
2. Observe that /wp-content/debug.log contains the following PHP notices (paths modified for privacy):

   [25-Feb-2022 18:06:08 UTC] PHP Notice:  Trying to get property 'title' of non-object in [...]/wp-includes/class-wp-customize-widgets.php on line 895
   

Expected Results (✅/❌)

• Patch addresses originally reported PHP notices. ✅
• Same notice appears in class-wp-customize-widgets.php in wordpress-develop:trunk. ❌

[costdev]

@ironprogrammer Thanks for testing!

I'll update the PR to address the other notice too.

[huskyr]

I'm having the same issue without the WooCommerce plugin, with a custom theme. I don't get the issue when switching to one of the standard themes. Is there a workaround without waiting for the upgrade?

[ironprogrammer]

Hi, @huskyr:

As this ticket addresses a PHP notice, it shouldn't impact site performance or the frontend. If the notice is visible in the admin UI, you could disable WP_DEBUG or WP_DEBUG_DISPLAY in wp-config.php.

I'm not aware of a workaround or fix you could apply to the custom theme, but if you wanted the proposed fix sooner than it ships, then you could apply the patch directly.

[ironprogrammer]

Adding screenshots that help clarify when these notices would appear. When the menus in question aren't enabled, their underlying markup is still emitted to the page, which triggers the notices.

Screenshots

Classic theme active, with Menus and Widgets support.

Block theme active (or classic theme w/o Menus and/or Widgets support), which triggers notice(s).

Example DOM footprint of a disabled customize-action with PHP notice (no Customizer widgets support).

[huskyr]

Hey ironprogrammer, thanks for the extensive explanation and screenshots! You're right, i don't see the notice on my production server because WP_DEBUG is indeed disabled there.

[audrasjb]

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

[azouamauriac]

Hi there, to reproduce the issue you should follow this step:
WordPress 5.9 hides the Customize menu item, if you are using a Full Site Editing theme, so you need to then access the /wp-admin/customize.php address manually to fully test this out.
as per this slack chat ​https://wordpress.slack.com/archives/C02RQBWTW/p1645644792576189

Replying to rafiahmedd:

@Boniu91 couldn't reproduce the same issue in my environment. Which version of PHP you are running?

[audrasjb]

Hello @costdev, are you still working on this PR?

Also @azouamauriac feel free to propose a new patch/PR to address the issue you underlined in the PR :)

[audrasjb]

This issue still needs a patch and WordPress 5.9.3 RC1 is scheduled tomorrow.
Moving for 5.9.4 consideration.

[azouamauriac]

Hello everyone, I will update the patch here shortly.

[azouamauriac]

Patch updated.

[ironprogrammer]

Thank you, @azouamauriac, for the updated patch!

Test Report

Patch 54905 👍🏻

Env

• WordPress 6.1-alpha-53344-src
• Chrome 100.0.4896.127
• macOS 12.3.1 (Monterey)
• Theme: Twenty Twenty-Two
• Gutenberg DISABLED 🔴
• Plugin: WooCommerce (activated, but not configured)
• In wp-config.php: define( 'WP_DEBUG_LOG', true );

Steps to Test (BEFORE PATCH)

1. Navigate to Appearance > Customize (menu enabled by WooCommerce).
2. Observe that upon page load, the following PHP notices are logged to /wp-content/debug.log (paths modified for privacy):

[03-May-2022 20:26:43 UTC] PHP Notice:  Trying to get property 'title' of non-object in [...]/wp-includes/class-wp-customize-nav-menus.php on line 523
[03-May-2022 20:26:43 UTC] PHP Notice:  Trying to get property 'title' of non-object in [...]/wp-includes/class-wp-customize-widgets.php on line 899
[03-May-2022 20:26:43 UTC] PHP Notice:  Trying to get property 'title' of non-object in [...]/wp-includes/class-wp-customize-nav-menus.php on line 1152

Steps to Test (AFTER PATCH)

1. Navigate to Appearance > Customize (menu enabled by WooCommerce).
2. Observe that on page load, the identified PHP notices are NOT logged to /wp-content/debug.log.

Expected Results (✅)

• The patch mitigates logging of the identified PHP notices.

[audrasjb]

Moving this ticket to next major release since it wasn't addressed during this cycle. Anyone is welcome to move it back to 6.0.x minor releases cycle if a patch is ready to ship.

[azouamauriac]

Replying to audrasjb:

Moving this ticket to next major release since it wasn't addressed during this cycle. Anyone is welcome to move it back to 6.0.x minor releases cycle if a patch is ready to ship.

This one has a patch though, and test report.

[hellofromTonya]

I'm wondering why this happens. Yes, I see the effect where the notification itself is happening due to no object being returned and no guard in place. However, going past this, how does the code even get to this point?

What do I mean?

With block themes, the intent is for the Menus and Widgets sections not be displayed in Customizer. Okay, then thinking more broadly, when should WP_Customize_Widgets and WP_Customize_Nav_Menus either bail out or not be instantiated?

Is the "removal" logic too late in the execution stack?
Is there an earlier approach to prevent unneeded code from executing? Resolving this fixes this ticket and enhances performance.

Off the top of my head, I'm not sure. Deeper dive is needed. Raising it here though for broader thinking and discussion.

[pbiron]

@hellofromTonya I haven't had a chance to look further into this since it was originally reported, but here are some thoughts I ​shared in slack at the time:

I'm not really familiar with most the code for ​WP_Customize_Nav_Menus but if $this->manager->get_panel( 'nav_menus' ) returns null then it seems like most (if not all) of the hooks added in __constuct() should just be skipped, right?

I'm sure I real fix is a little more complicated than that, but it seems that a deeper dive into how each of the Composer objects initialize themselves is needed.

[dlh]

#56142 was marked as a duplicate.

[bobbingwide]

My patch for #56142 was different from the one attached here.
It covers an additional Warning message for when Widgets are not supported either.

[bobbingwide]

Patch for 56142 - a duplicate of 54905 - to avoid 3 Warning messages from the Customizer for FSE theme

[westonruter]

After a lot of digging, I finally found the cause. The issue was introduced in [52621] where a WP_Customize_Nav_Menus_Panel::check_capabilities() method override was introduced which caused the return to be false if the current theme doesn't support menus nor widgets. Original PR: ​https://github.com/WordPress/wordpress-develop/pull/2217

The problem is that since check_capabilities returns false, when WP_Customize_Manager::prepare_controls() runs it will remove any registered panels that the user doesn't have the capability to manage.

Ironically, I actually reviewed that PR and I thought the approach would work, but clearly it doesn't. I did provide an alternative solution, however, which should actually fix the issue here: ​https://github.com/WordPress/wordpress-develop/pull/2217#discussion_r790977534

I'll create a patch for this.

The issue was introduced in ​https://github.com/WordPress/wordpress-develop/pull/2217 where a WP_Customize_Nav_Menus_Panel::check_capabilities() method override was introduced which caused the return to be false if the current theme doesn't support menus nor widgets.

The problem is that since check_capabilities returns false, when WP_Customize_Manager::prepare_controls() runs it will remove any registered panels that the user doesn't have the capability to manage.

Ironically, I actually reviewed that PR and I thought the approach would work, but clearly it doesn't. I did provide an alternative solution, however, which should actually fix the issue here: ​https://github.com/WordPress/wordpress-develop/pull/2217#discussion_r790977534

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

[westonruter]

@bobbingwide My patch doesn't impact class-wp-customize-widgets.php as yours does. I wasn't able to reproduce the issue with widgets, however. This ticket is specifically regarding menus nonetheless.

Makes sense. Marking the panel as inactive instead of removing it would indeed make it so that calls to get_panel( 'nav_menus' ) don't return an empty value.

What I'm wondering though is: why do we even run WP_Customize_Nav_Menus::available_items_template, WP_Customize_Widgets::output_widget_control_templates, and WP_Customize_Nav_Menus::enqueue_scripts when the theme doesn't support menus nor widgets? It doesn't seem to me that there should ever be a call to get_panel( 'nav_menus' ) when we know that there won't be a panel with that ID.

Yes. Really the Widgets and Nav Menus components should be disabled entirely. There is a filter for that: ​`customize_loaded_components`. However, I do not believe it will work here because it has to run when WP_Customize_Manager is constructed which happens at plugins_loaded, and thus before the theme is loaded. This means it would run too early to check if wp_is_block_theme(), right?

Yeah that's right. Bummer!

OK, marking as inactive seems reasonable all things considered 👍

[desrosj]

@westonruter Are you able to get this refined and committed prior to RC on this upcoming Tuesday?

[westonruter]

@desrosj yes, I can commit the PR today. My intention is to commit the PR as-is unless there is additional feedback.

[westonruter]

In 54419:

Customize: Prevent PHP notice in Customizer when using block theme.

Use the customize_panel_active filter to deactivate the Menus panel instead of overriding the check_capabilities method. This ensures the panel remains registered but is still hidden.

See #54888.
Fixes #54905.

Committed to trunk in https://core.trac.wordpress.org/changeset/54419