WordPress.org

Make WordPress Core

Opened 3 years ago

Closed 2 years ago

#18475 closed defect (bug) (fixed)

get_post_type_object is sometimes passed an array

Reported by: t31os_ Owned by: nacin
Milestone: 3.3 Priority: normal
Severity: minor Version: 3.2.1
Component: Posts, Post Types Keywords: has-patch
Focuses: Cc:

Description

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.

Attachments (1)

18475.diff (2.1 KB) - added by scribu 3 years ago.

Download all attachments as: .zip

Change History (8)

comment:1 scribu3 years ago

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

https://gist.github.com/625769

Version 0, edited 3 years ago by scribu (next)

comment:2 scribu3 years ago

  • Milestone changed from Awaiting Review to 3.3

I can see the errors too.

scribu3 years ago

comment:3 scribu3 years ago

  • Keywords has-patch added; needs-patch removed

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

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

comment:4 t31os_3 years ago

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?

Last edited 3 years ago by t31os_ (previous) (diff)

comment:5 nacin2 years ago

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().

comment:6 nacin2 years ago

In [19192]:

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

comment:7 nacin2 years ago

  • Owner set to nacin
  • Resolution set to fixed
  • Status changed from new to closed

In [19193]:

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

Note: See TracTickets for help on using tickets.