[wp-trac] [WordPress Trac] #17025: wp_list_authors() is not filterable

[WordPress Trac]

#17025: wp_list_authors() is not filterable
------------------------------------+------------------
 Reporter:  kevinB                  |       Owner:
     Type:  enhancement             |      Status:  new
 Priority:  normal                  |   Milestone:  3.7
Component:  Query                   |     Version:
 Severity:  normal                  |  Resolution:
 Keywords:  has-patch dev-feedback  |
------------------------------------+------------------

Comment (by 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 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'";
 }}}

 A filter on the results would be better than nothing, but it has the
 disadvantage of forcing an additional query.

--
Ticket URL: <http://core.trac.wordpress.org/ticket/17025#comment:11>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software