Filtering show_post_format_ui and returning false results in a fatal error

[tlovett1]

Title says it all. Filtering and returning false results in this error on the post edit screen:

Catchable fatal error: Object of class CLASS_ADDING_FILTER could not be converted to string in /srv/www/trunk/wp-admin/edit-form-advanced.php on line 409

My patch simple declares $post_format_options outside of the if statement. Since the variable was getting checked with empty() and it wasn't initialized, it was passing through the check resulting in a fatal error.

[tlovett1]

Patch moves $post_format_options outside of if statement checking show_post_format_ui filter

[nacin]

I see how this could be a notice, but I think I'm missing how it fatals. Could you give us a snippet of code with the filter that triggers this?

[SergeyBiryukov]

An empty() check doesn't require the variable to be initialized.

From the error message, looks like you're redefining the $post_format_options global with your class.

[tlovett1]

Yep, just caught this. False alarm. I globalized a variable $post_format_options in a plugin. The variable should still be moved outside the conditional, however. It is very possible people will globalize a variable called $post_format_options.

[SergeyBiryukov]

Reproduced the error with this snippet:

add_filter( 'show_post_format_ui', '__return_false' );
$post_format_options = new stdClass;

patch-post-format-filter-fix.diff​ makes sense to me.

[SergeyBiryukov]

In 24011:

Make sure the variables are always defined. props tlovett1, danielbachhuber. fixes #24034. fixes #24112.