wp_list_authors() is not filterable

[kevinB]

The template function wp_list_authors() is not filterable. Plugins may use existing WP_Query hooks to filter some authors' posts out of the result set, making the unfiltered authors list invalid.

The corresponding patch adds query filter 'list_authors_query'

[kevinB]

query filter for wp_list_authors()

[scribu]

Related: #17022

[wonderboymusic]

The filter seems reasonable.

[wonderboymusic]

There's a new filter

[DrewAPicture]

filter docs

[DrewAPicture]

17025.2.diff​ adds a docblock for the list_authors_query filter hook.

[nacin]

I would prefer to not add a filter that directly operates on SQL. This is not very flexible or fun.

Can we instead filter A) $authors, and/or B) $author_count?

Also: Unless I am reading it wrong, this function also appears to be very, unnecessarily heavy. By only asking for 'ids' from get_users(), none of the users are getting cached, which means each individual call to get_usermeta() is triggering a new query.

It would make more sense to run the raw query first, then fetch only those user objects (see also cache_users(); get_users() can also do this), unless $hide_empty is false, in which case you still need to fetch all objects as we're doing now.

[wonderboymusic]

see @nacin's comment - needs alternate filter approach

[DrewAPicture]

Alternate approach

[DrewAPicture]

Would something like 17025.3.diff​ work better?

[DrewAPicture]

'ids' fallback for false $hide_empty

[kevinB]

This request was part of a handful which I tossed out a couple years ago with an overall goal of allowing records to be filtered out of or into the result set. Filters applied in WP_Query and elsewhere make it possible to elevate the logged user to (or demote them from) author capabilities contextually based on criteria which WP core need not be aware of nor formally support. But some of the corresponding "user assignment" UI does not permit corresponding filtering.

wp_list_authors() is low-priority to me since it's not called by core. But inevitably some plugins and themes use it in a way that doesn't mesh with per-user inclusion/exclusion I do with WP_Query filters. Then I'll have to filter every query and use strpos() and preg_match() to determine if it is the wp_list_authors() query. Now that's not fun. So basically, the significance of this ticket is in setting a precedent for whether the API fully supports external modification of content and user queries, or whether it presumes to anticipate and regulate all implementations.

In this case, caching the "all objects" results of the default query is not sufficient since it is built on query clauses that do not account for post types other than 'post' nor visibility statuses other than 'private':

"SELECT DISTINCT post_author, COUNT(ID) AS count FROM $wpdb->posts WHERE post_type = 'post' AND " . get_private_posts_cap_sql( 'post' )

The 'pub_priv_sql_capability' filter in function get_posts_by_author_sql() would at least allow a different post type for the current user capability check, but even that is up for deprecation according to the inline comment. And then you still have this:

$sql .= " OR post_status = 'private'";

So a filter on the results would be better than nothing, but it has the disadvantage of forcing an additional query, which makes plugins look bad ;)

[nacin]

There's a lot going on here. Moving to 3.8.

[wonderboymusic]

@DrewAPicture probably wants to update his patch/docs

[DrewAPicture]

refresh

[DrewAPicture]

17025.5.diff​ refreshes the patch.

[DrewAPicture]

refresh

[DrewAPicture]

Let's work on this in 4.1. 17025.6.diff​ refreshes the patch at r29015. Unit tests might also need an update for $hide_empty.

[Mte90]

patch refreshed for 4.6

[Mte90]

optimized foreach moving query outside

[Mte90]

Patch refreshed, updated code and splitted in two patch.
17025.7.diff contain the new filter and 17025.optimizeforeach.diff contain the optimization of the foreach of the original patch.

[jorbin]

@DrewAPicture and @boonebgorges Can you two take a look? Would love to know your thoughts.

[Mte90]

any chance for the 4.7?

[afercia]

17025.optimizeforeach.diff​ needs some coding standards: spacing, empty lines should not have spaces, etc.