Allow filtering by author on Manage > Posts

[jeremyclarke]

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.

[ryan]

Moving enhancements to 2.8.

[Denis-de-Bernardy]

​http://core.trac.wordpress.org/report/19

[scribu]

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

[scribu]

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.

[scribu]

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

Anyway: #15085

[scribu]

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.

[johnbillion]

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

[jeremyclarke]

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.

[scribu]

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

[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.

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.

[Master Jake]

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]

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.

[DrewAPicture]

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]

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.

[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.

[Master Jake]

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?

[DrewAPicture]

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.

[swissspidy]

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