Array to string conversion notice when multiple post types are queried in edit.php

[jeremyfelt]

In edit.php, the requested list table post type is captured as the global $typenow and then assigned to the global $post_type. This $post_type string is then used to display help tabs, to fire a filter for screen options, and as a value for a hidden input.

If a plugin modifies a query - either accidentally or intentionally - to include multiple post types by using $query->set( 'post_type', array( 'page', 'my_post_type' ); on parse_query, the global $post_type is then turned into an array through wp->register_globals() and an "array to string conversion" notice is shown.

We should probably treat the global $post_type separately from the string required to make the page display properly.

[Kloon]

Ensure typenow is a string on edit.php

[Kloon]

Since edit.php does not support multiple post types the patch does a check to ensure that the $typenow var is a string.

[nacin]

As noted in a code review during a video call with the Cape Town contributor day, I don't think this patch fixes the notice that was reported. $typenow is set in admin.php only if the post type exists, which means it's going to be a string once we get to edit.php.

jeremyfelt was reporting that wp_edit_posts_query() ends up running $wp->register_globals() which sets up the $post_type global (why do we even do this in the admin? ugh) which if the post_type query variable was modified on parse_query or whatever, the $post_type global would then be an array. I don't think it actually has anything to do with $typenow; that's just the starting value for $post_type.

That said, edit.php?post_type[]=post&post_type[]=page *does* result in this notice involving $typenow:

• PHP Warning: Illegal offset type in isset or empty in /Users/nacin/Sites/develop/src/wp-includes/post.php on line 1151

To fix that, we'd need to put an is_string() check in get_post_type_object(). I think it's hypothetically possible for a post type name to be an integer due to the way PHP handles numeric strings as an array key (it doesn't), so it's possible that is_scalar() is a better check. That would simply avoid the warning and let isset() do its work.

A simple unit test for the latter issue might look like this:

# in tests/phpunit/tests/post/types.php, these new methods in Test_Post_Types:
function test_get_post_type_object_with_non_scalar_values() {
    $this->assertFalse( get_post_type_object( array() );
    $this->assertFalse( get_post_type_object( new stdClass );
}

This test would never "fail" in the sense that false would be returned, but the test would error out due to the warning, producing an E result.

[Kloon]

Do check in get_post_type_object() instead of $typenow as per Nacin's feedback

[Kloon]

Unit test get_post_type_object function with non scalar values

[Kloon]

Hopefully I did this right, added unit test and patch in separate diffs.

[norcross]

saw there's also an array to string conversion error in the same file on lines 237 and 319

line 237: add_screen_option( 'per_page', array( 'default' => 20, 'option' => 'edit_' . $post_type . '_per_page' ) );

line 319: <input type="hidden" name="post_type" class="post_type_page" value="<?php echo $post_type; ?>" />

not sure if this should be in the same patch or not

[wonderboymusic]

30013.3.diff​ combines/refreshes

[wonderboymusic]

In 34100:

Check if the $post_type passed to get_post_type_object() is a scalar value. Non-scalars were producing PHP warnings.

Adds unit tests.

Props Kloon.
Fixes #30013.

[dingo_bastard]

Is this still an issue or is this completely fixed? I added a filter to my custom post type, and got the warning pointing to

/wp-admin/edit.php on line 257
/wp-admin/edit.php on line 342

I removed the custom made filter, and when trying to filter out my custom post type by date, I still got the same notice (plus nothing actually gets filtered). The code is located here if anyone's interested: ​https://gist.github.com/dingo-d/a770ed318de55dd380ef80b73733abf3

I checked every part of my code, just to insure it's not something I did, but it seems fine.

Is there a workaround for this?