WordPress.org

Make WordPress Core

Opened 3 years ago

Last modified 7 months ago

#17025 new enhancement

wp_list_authors() is not filterable

Reported by: kevinB Owned by:
Milestone: Future Release Priority: normal
Severity: normal Version:
Component: Query Keywords: has-patch dev-feedback 3.8-early
Focuses: Cc:

Description

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'

Attachments (5)

list-authors_filter_3.2.patch (874 bytes) - added by kevinB 3 years ago.
query filter for wp_list_authors()
17025.diff (929 bytes) - added by wonderboymusic 9 months ago.
17025.2.diff (1.0 KB) - added by DrewAPicture 7 months ago.
filter docs
17025.3.diff (1.6 KB) - added by DrewAPicture 7 months ago.
Alternate approach
17025.4.diff (1.7 KB) - added by DrewAPicture 7 months ago.
'ids' fallback for false $hide_empty

Download all attachments as: .zip

Change History (18)

kevinB3 years ago

query filter for wp_list_authors()

comment:1 scribu3 years ago

Related: #17022

comment:2 scribu3 years ago

  • Summary changed from add hook for wp_list_authors() to wp_list_authors() is not filterable

wonderboymusic9 months ago

comment:3 wonderboymusic9 months ago

  • Milestone changed from Awaiting Review to 3.7

The filter seems reasonable.

comment:4 wonderboymusic7 months ago

  • Keywords needs-docs added

There's a new filter

DrewAPicture7 months ago

filter docs

comment:5 DrewAPicture7 months ago

  • Keywords commit added; needs-docs removed

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

comment:6 nacin7 months ago

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.

comment:7 ocean907 months ago

  • Keywords commit removed

comment:8 wonderboymusic7 months ago

  • Keywords needs-refresh added

see @nacin's comment - needs alternate filter approach

DrewAPicture7 months ago

Alternate approach

comment:9 DrewAPicture7 months ago

  • Keywords dev-feedback added; needs-refresh removed

Would something like 17025.3.diff work better?

DrewAPicture7 months ago

'ids' fallback for false $hide_empty

comment:10 DrewAPicture7 months ago

  • Cc xoodrew@… added

comment:11 kevinB7 months ago

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 ;)

Last edited 7 months ago by kevinB (previous) (diff)

comment:12 alex-ye7 months ago

  • Cc nashwan.doaqan@… added

comment:13 nacin7 months ago

  • Keywords 3.8-early added
  • Milestone changed from 3.7 to Future Release

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

Note: See TracTickets for help on using tickets.