get_post_type_object is sometimes passed an array

[t31os_]

The get_post_type_object function does not support arrays, yet it seems at times the value passed to it will be an array.

In some cases the $post_type global is passed to the function as an array, this in turn generates notices because the function is expecting a string.

Typically you'll see something like..

Warning: Illegal offset type in isset or empty in C:\path\to\install\wp-includes\post.php on line 825

And potentially 2 more additional notices can be generated by wp_count_posts which is passed the $post_type global by get_views().

File: class-wp-posts-list-table.php
Lines: 129 - 136

	function get_views() {
		global $post_type, $post_type_object, $locked_post_status, $avail_post_stati;

		if ( !empty($locked_post_status) )
			return array();

		$status_links = array();
		$num_posts = wp_count_posts( $post_type, 'readable' );

For an easy demostration of an array of values being passed, open edit.php in your install with post_format passed as a query var, eg. wp-admin/edit.php?post_format=aside.

I'm not sure why that particular query puts the post type into an array(it shows up as an array inside the WP_Query object to). Passing &post=type=post into the query string does not change the outcome and i'm not sure on what the cause is, the only place i could see any $post_type variable cast to an array is inside update_post_caches(), though it's my understanding WP_Query does support passing an array of post types to the query, so perhaps it's a side-effect of something there.

Tested without any plugins enabled, and with the theme's functions file stripped down(ie. empty).

NOTE: Despite the notices, the post_format query var does work, and return the correct result set.

[scribu]

You can make errors display a backtrace, to help pinpoint the error, by installing the following mu-plugin:

​https://gist.github.com/625769

[scribu]

I can see the errors too.

[scribu]

It seems to be set somewhere deep in the main query code.

Workaround is to not use the $post_type global. See 18475.diff​.

[t31os_]

Should the global be getting filled with an array of post types anyway? I've always been under the impression it would(or should, perhaps?) contain a singular string value denoting the type of post type page you are viewing admin side, ie. if i'm managing a "book" post type, that value is naturally "book", and not necessarily array( 'book' )...

I can understand why WP_Query supports an array(for grabbing a result set of more than 1 post type), but should the global also contain an array of post types?

[nacin]

It took me and ethitter quite a while to track this one down.

The issue is _post_format_request(), which hooks into the request filter and corrects the post_type query variable based on the post_format's object_type setting. object_type is always cast to an array, even if it is singular.

In the admin, post_type will always be singular wherever we use wp(). So what we should also do is prevent the callback from overriding the post_type query variable in the admin.

Finally, this gets extracted into the global namespace via WP::register_globals(). There's little reason for the query variables to be extracted back out into the admin namespace when we call wp() on edit.php and upload.php. Erick tested bypassing the query_vars extraction in the admin, and nothing seemed to break, but I'm sure some plugin is doing something terrible there.

Regardless, I agree with 18475.diff​. One less global to rely on. I'm also going to fix _post_format_request().

[nacin]

In [19192]:

Don't use $post_type global in the posts list table. props scribu, see #18475.

[nacin]

In [19193]:

Don't set post_type QV in _post_format_request() when we're in the admin. props ethitter. fixes #18475.