Make WordPress Core

Opened 9 years ago

Closed 9 years ago

#33449 closed defect (bug) (fixed)

WP_User_Query generating notice (undefined index has_published_posts)

Reported by: veraxus's profile Veraxus Owned by: boonebgorges's profile boonebgorges
Milestone: 4.4 Priority: normal
Severity: normal Version: 4.3
Component: Query Keywords: needs-patch reporter-feedback
Focuses: Cc:


The new 'has_published_posts' (see #32250) parameter in 4.3 is incorrectly handled by the class, and generates a notice...

Notice: Undefined index: has_published_posts in /Users/Matt/Dropbox/_Web Projects/ on line 662

Line 662 reads:

if ( $qv['has_published_posts'] && $blog_id ) {

But it should read:

if ( isset( $qv['has_published_posts'] ) && $blog_id ) {

This makes it consistent with the rest of the properties handled by the class. Patch is attached.

Attachments (1)

wp-user-query.patch (517 bytes) - added by Veraxus 9 years ago.
Fixes notice generated by WP_User_Query introduced in 4.3

Download all attachments as: .zip

Change History (10)

9 years ago

Fixes notice generated by WP_User_Query introduced in 4.3

#1 @Veraxus
9 years ago

  • Keywords has-patch added

#2 @dd32
9 years ago

IMHO this is showing something deeper - $this->query_vars = wp_parse_args(..) isn't being run in all cases, so $this->query_vars might not get filled with the defaults.

At present the class adds a lot of isset() checks, checks that shouldn't be needed if the defaults were being filled correctly.

@Veraxus is the notice being generated by a custom WP_User_Query instance? Can you let us know how you're calling the class?

#3 @boonebgorges
9 years ago

  • Keywords needs-patch reporter-feedback added; has-patch removed
  • Milestone changed from Awaiting Review to 4.4

I think this is probably happening because a plugin (or something) is overriding query vars in a funny way. Here are two different ways to cause notices like the ones reported here:

$q = new WP_User_Query();
$q->query_vars = array( 'foo' => 'bar' );
add_action( 'pre_get_users', function( $q ) {
    $q->query_vars = array( 'foo' => 'bar' ); 
} );

$args = array( ... );
$q = new WP_User_Query( $args );

In both cases, query_vars is being manipulated manually. If you pass a dumb array like array( 'foo' => 'bar' ) you will see a ton of notices. My guess is that a plugin is passing a relatively comprehensive of query vars, but it hasn't been updated to include 'has_published_posts', so you're only seeing a notice for that one.

As dd32 hints, we should probably be running wp_parse_args() in all cases, and possibly after the 'pre_get_users' filter, to make sure all values are set. (See WP_Query::fill_query_vars() and 'pre_get_posts'.)

#4 @Veraxus
9 years ago

I'm seeing these in all projects were Posts 2 Posts has been used, and even a couple where it isn't (but where custom user queries are very likely being used). As @dd32 pointed out, this may need a more comprehensive fix than I proposed to fix a deeper underlying issue.

The class shouldn't throw notices simply because query_vars wasn't passed a comprehensive list of arguments. A default-setting process ( e,g, $this->query_vars = wp_parse_args( … ) ) really should run each time WP_User_Query is used.

#5 @Gwendydd
9 years ago

For what it's worth, I am also seeing this error on sites using Posts 2 Posts to connect users to other post types.

This ticket was mentioned in Slack in #core by sergey. View the logs.

9 years ago

#8 @SergeyBiryukov
9 years ago

  • Owner set to boonebgorges
  • Status changed from new to assigned

#9 @boonebgorges
9 years ago

  • Resolution set to fixed
  • Status changed from assigned to closed

In 34804:

Ensure that WP_User_Query vars are filled after 'pre_get_users'.

This prevents notices from being thrown when a 'pre_get_users' callback
removes required values from the list of query_vars.

For backward compatibility with previous uses of 'pre_get_users', default
values are parsed both before and after the action is fired.

Fixes #33449.

Note: See TracTickets for help on using tickets.