WordPress.org

Make WordPress Core

Opened 12 years ago

Closed 5 years ago

#7723 closed enhancement (maybelater)

Allow filtering by author on Manage > Posts

Reported by: jeremyclarke Owned by:
Milestone: Priority: normal
Severity: normal Version:
Component: Posts, Post Types Keywords: has-patch dev-feedback needs-testing
Focuses: Cc:

Description

In versions of wp before 2.5 you could select an author from a dropdown on MANAGE > POSTS to see only posts owned by that author. This was very useful for quickly sorting posts and is absolutely necessary when you have editor users without the 'edit_users' capability, as unlike admin users (most of us) they don't have access to the 'users' tab and thus have no way to see the manage screen sorted by user. The manage screen sorts by user simply by adding ?&author=$id in the url, but for users without access to the 'users' tab, even author id's are innaccessible.

In the #wordpress-dev irc channel ryan boren expressed that the filter was removed because in some cases there were too many users in the system and the resulting dropdown was slowing down pageload time and ruining user experience. This is a paradox, because the more users your system has the more likely you are to need this filter.

Wordpress needs to support filtering by author somehow if it wants to be a serious multi-user platform. Our editors are pulling out their hair.

My personal opinion is that the dropdown select should be reinstated. Filters should be added to the list such that only users who can post are listed (other users have no use in the Manage > Posts screen), as well as to show only users with at least 1 post. This should avoid slowing down pages for installations where most users are 'subscribers', which would otherwise mean all open-registration blogs would have hugely long lists.

Given those two filters, I think that anyone who still has load-time problems should deal with their problem themselves using a plugin. It should be easy to remove the filter dropdown if you don't want it using a plugin, as well as to further filter the authors shown to reduce their number.

Any installation with that many users deserves the option of deciding if they want the pulldown or not, and I think many would choose to keep it even if there are problems because it is so incredibly useful in filtering through hundreds of users worth of posts.

(Consider: the full categories list is shown, even if there are hundreds, despite the fact that this has the same effect on performance as many authors does).

Also in IRC Matt M proposed that some kind of text box + ajax to predict which author you mean could be used for this purpose. I think that is a great idea but would take a lot more work than what I propose (the work for hte pulldown is already done and the old functions are still there, all that's needed is to add filtering and re-work it into edit.php). It could also be used in the 'Users' context for search though, so it could be worth the effort.

Attachments (2)

7723-01.diff (4.4 KB) - added by Master Jake 7 years ago.
7723-02.diff (5.4 KB) - added by Master Jake 7 years ago.

Download all attachments as: .zip

Change History (26)

#1 @ryan
12 years ago

  • Milestone changed from 2.7 to 2.8

Moving enhancements to 2.8.

#2 @FFEMTcJ
11 years ago

  • Keywords needs-patch added
  • Milestone changed from 2.8 to Future Release

#3 @Viper007Bond
11 years ago

  • Component changed from General to Administration
  • Summary changed from Allow filtering by author on Manage > posts (or its new crazyhorse name) to Allow filtering by author on Manage > Posts

#4 @Denis-de-Bernardy
11 years ago

  • Milestone changed from Future Release to 2.9

#5 @Denis-de-Bernardy
11 years ago

  • Milestone changed from 2.9 to Future Release

#6 @scribu
10 years ago

  • Milestone Future Release deleted
  • Resolution set to wontfix
  • Status changed from new to closed

Not gonna happen. If you want the dropdown back, use a plugin.

#7 @scribu
10 years ago

Also in IRC Matt M proposed that some kind of text box + ajax to predict which author you mean could be used for this purpose.

Instead of having a dropdown for categories, one for authors etc., we could have a single auto-suggest field like that and a dropdown next to it, where you could choose what to filter: categories, authors, tags etc.

#8 @scribu
10 years ago

Of course, then someone will come up and say: hey, I need to filter by author AND by category. :)

Anyway: #15085

#9 @scribu
9 years ago

  • Milestone set to Future Release
  • Resolution wontfix deleted
  • Status changed from closed to reopened

I've come around on this.

  1. Categories are hierarchical, something which can't be conveyed using an auto-suggest.
  2. Although there can be hundread of categories, there can be a lot more users.

So yeah, if someone comes up with a patch, we can use an author auto-suggest both as a filter and to replace the dropdown present on the single post editing screen.

#10 follow-up: @johnbillion
9 years ago

An auto-suggest for users seems like a strange UI choice for sites with a handful of users. If a site has 5 users then a dropdown is much better. If it has 10 or 15 users a dropdown is probably better too. For 20 users it's borderline. Maybe the dropdown should be reinstated, but if there are more than X users then an auto-suggest is used instead, with X being somewhere around 20 or 25 (filterable of course).

#11 @DrewAPicture
9 years ago

  • Cc xoodrew@… added

#12 in reply to: ↑ 10 @jeremyclarke
9 years ago

Replying to johnbillion:

Maybe the dropdown should be reinstated, but if there are more than X users then an auto-suggest is used instead, with X being somewhere around 20 or 25 (filterable of course).

+1 sounds like a really good solution. A dropdown with hundreds of users would be very hard to use (though still useful compared to nothing!) and a auto-suggest for 3 authors would just seem ridiculous to people who don't realize there are WP sites with hundreds of authors.

#13 @scribu
9 years ago

Conversely, if there's only one author, we shouldn't show the dropdown at all. We have an is_multi_author() conditional tag now.

#14 follow-up: @johnbillion
9 years ago

I wonder how the auto-suggest input would work, as the 'author' parameter takes a user ID. It wouldn't work if the auto-suggest field worked the same way as the tag input works, for example.

Additionally, there's not a lot of space on the row where those controls are displayed so we might be tight for space. I don't think the bulk actions menu existed when the author dropdown was there originally.

#15 @Master Jake
7 years ago

  • Cc chappellind@… added

#16 in reply to: ↑ 14 @Master Jake
7 years ago

Replying to johnbillion:

I wonder how the auto-suggest input would work, as the 'author' parameter takes a user ID. It wouldn't work if the auto-suggest field worked the same way as the tag input works, for example.

I was thinking the auto-complete would be for name, but we could hook in and send the author's id to a hidden input field which is sent to the query string on submit.

@Master Jake
7 years ago

#17 @Master Jake
7 years ago

  • Keywords has-patch dev-feedback needs-testing added; needs-patch removed

Patch 7723-01.diff addresses the discussed concerns.

The patch includes a dropdown if the number of authors is below the threshold (default is 20, filterable, filter name may need to change), or a textbox that uses jQuery Autocomplete with custom source for authors above the threshold.

Needs some cross browser testing for UI, and some testing in general for functionality.

#18 @DrewAPicture
7 years ago

7723-01.diff looks like a pretty good start.

Just a couple of suggestions:

  • There's no need to break the ternary logic onto multiple lines such as in 234-237 in class-wp-posts-list-table.php. Core style is generally one line.
  • We should also be checking against wp_is_large_network() in the count-check to avoid performance issues for sites with > 10,000 users.
  • For the input placeholder and option value, we can use esc_attr_e() and esc_html_e() respectively for outputting the strings

@Master Jake
7 years ago

#19 follow-up: @Master Jake
7 years ago

Thank you for the suggestions, DrewAPicture!

Patch 7723-02.diff addresses them.

I also noticed that, silly me, I forgot to include the post-filters.js in the last patch. It is in this patch.

A couple of my own concerns involve the naming convention of the new filter and HTML form elements. Additionally, I found it necessary to introduce a new JavaScript file (the post-filters.js), because I did not see one that was immediately related to what we needed. Perhaps I am wrong though, and we could roll the post-filters.js into another JavaScript file that is loaded on the edit.php page.

#20 in reply to: ↑ 19 ; follow-up: @DrewAPicture
7 years ago

Replying to Master Jake:

Additionally, I found it necessary to introduce a new JavaScript file (the post-filters.js), because I did not see one that was immediately related to what we needed. Perhaps I am wrong though, and we could roll the post-filters.js into another JavaScript file that is loaded on the edit.php page.

Actually, you might be able to roll the js into user-suggest.js in /wp-admin/js/. It's used for user-autocomplete for Multisite that was added in 3.4, see #19810.

#21 in reply to: ↑ 20 ; follow-up: @Master Jake
7 years ago

Replying to DrewAPicture:

Replying to Master Jake:

Additionally, I found it necessary to introduce a new JavaScript file (the post-filters.js), because I did not see one that was immediately related to what we needed. Perhaps I am wrong though, and we could roll the post-filters.js into another JavaScript file that is loaded on the edit.php page.

Actually, you might be able to roll the js into user-suggest.js in /wp-admin/js/. It's used for user-autocomplete for Multisite that was added in 3.4, see #19810.

That script certainly has the same dependencies and seems like it would work. However, it doesn't appear like its enqueued on the edit.php page right now, unless I overlooked something. Are you suggesting we go ahead and enqueue it on edit.php as well?

#22 in reply to: ↑ 21 @DrewAPicture
7 years ago

Replying to Master Jake:

Replying to DrewAPicture:

Actually, you might be able to roll the js into user-suggest.js in /wp-admin/js/. It's used for user-autocomplete for Multisite that was added in 3.4, see #19810.

That script certainly has the same dependencies and seems like it would work. However, it doesn't appear like its enqueued on the edit.php page right now, unless I overlooked something. Are you suggesting we go ahead and enqueue it on edit.php as well?

Not sure what the protocol is on mixing scripts in this way. The only reason I suggested it is that it might just be more efficient to combine the two as they both use autocomplete for a similar purpose.

#23 @iseulde
5 years ago

  • Component changed from Administration to Posts, Post Types

#24 @swissspidy
5 years ago

  • Milestone Future Release deleted
  • Resolution set to maybelater
  • Status changed from reopened to closed

Closing as maybelater until we have better solutions dropdown with lots of users (#19867) and autocomplete/suggestions for such dropdowns (#31696).

Note: See TracTickets for help on using tickets.