[PHP 8.0] Undefined property: stdClass::$post_status on /wp-admin/includes/misc.php

[GwynethLlewelyn]

I'm happily upgrading many of my WordPress installations to PHP 8.0.0 just to see what breaks.

Here is one 'warning' that I caught today on one of my websites:

PHP Warning:  Undefined property: stdClass::$post_status in <WP_PATH>/wp-admin/includes/misc.php on line 1433

The fix is trivial, instead of

<?php
if ( 'draft' === $page->post_status && 'privacy' === get_current_screen()->id ) {

just use

<?php
if ( !empty($page->post_status) && 'draft' === $page->post_status && 'privacy' === get_current_screen()->id ) {   

... or, alternatively, use ​property_exists(), isset(), etc.

It's a very trivial change to avoid a warning; possibly it's present under PHP 7.4 as well.

[ayeshrajans]

Hi @GwynethLlewelyn,
Welcome to WordPress Trac, and I wish you a happy new year!

You are right, the warning is related to PHP 8, which was previously a notice, and it is possible that your previous configuration options was not logging/showing those notices (although PHP was configured to show notices by default; just not strict and deprecation notices).

Could you provide a stack trace of the warning message? debug_print_backtrace() output or an Xdebug output will do. Instead of fixing this when it is used, I think a more appropriate fix would be to fix it in upstream, where the post is constructed to make sure post_status is correctly populated.

Cheers.

[SergeyBiryukov]

Hi there, thanks for testing WordPress with PHP 8.0!

Does the issue still happen with all plugins disabled and a default theme (Twenty Twenty-One) activated?

The warning comes from the _wp_privacy_settings_filter_draft_page_titles() function, which is attached to the list_pages action in the admin, called from Walker_PageDropdown::start_el(). The action is supposed to always receive a valid page data object a its second argument, so it looks like some plugin or theme constructs an object with some properties missing, or uses the list_pages filter incorrectly, which seems like a developer error.

I don't think we should hide the warning in this case, as that would make debugging harder.

[GwynethLlewelyn]

Sorry for the delay in answering...

@SergeyBiryukov you're quite right!

Also, now I cannot reproduce the error on my own setup — I've updated/upgraded a few plugins, removed others, deactivated a few more... this is a work-in-progress, mind you... and probably at some point, I must have removed whatever plugin was causing the warning.

I'll close this ticket for now; I've kept debug_print_backtrace() in place, just in case that it pops up again...

Thanks anyway for looking into this! 😊

[SergeyBiryukov]

Thanks for the follow-up!