WP_User_Query generating notice (undefined index has_published_posts)

[Veraxus]

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/website.dev/wp-includes/user.php 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.

[Veraxus]

Fixes notice generated by WP_User_Query introduced in 4.3

[dd32]

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?

[boonebgorges]

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' );
$q->prepare_query();

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

[Veraxus]

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.

[Gwendydd]

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

[Gwendydd]

This patch in Posts 2 Posts gets rid of the errors: ​https://github.com/scribu/wp-lib-posts-to-posts/commit/65388a6cf4fcd748cca3f4785b48883a039a4cd6

[boonebgorges]

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.