[wp-trac] [WordPress Trac] #30013: Array to string conversion notice when multiple post types are queried in edit.php

[WordPress Trac]

#30013: Array to string conversion notice when multiple post types are queried in
edit.php
-------------------------------------------------+-------------------------
 Reporter:  jeremyfelt                           |       Owner:
     Type:  defect (bug)                         |      Status:  new
 Priority:  normal                               |   Milestone:  Future
Component:  Posts, Post Types                    |  Release
 Severity:  normal                               |     Version:
 Keywords:  good-first-bug needs-patch needs-    |  Resolution:
  unit-tests                                     |     Focuses:
                                                 |  administration
-------------------------------------------------+-------------------------
Changes (by nacin):

 * keywords:  good-first-bug has-patch => good-first-bug needs-patch needs-
     unit-tests


Comment:

 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.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/30013#comment:3>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform