[wp-trac] [WordPress Trac] #19867: wp_dropdown_users() still not scalable
WordPress Trac
noreply at wordpress.org
Wed Mar 26 19:01:14 UTC 2014
#19867: wp_dropdown_users() still not scalable
-------------------------------------+------------------------------
Reporter: prettyboymp | Owner:
Type: defect (bug) | Status: new
Priority: normal | Milestone: Future Release
Component: Users | Version: 3.3.1
Severity: normal | Resolution:
Keywords: has-patch needs-refresh | Focuses: ui, performance
-------------------------------------+------------------------------
Changes (by helen):
* milestone: 3.9 => Future Release
Comment:
I dove way down, and didn't come back up in time for 3.9. Here's where I
landed (with help from gcorne). '''tl;dr:''' Autocomplete needs to enhance
the right UI for the given data, whether that's a text input, a select
element, or something else.
We have two instances of jQuery UI autocomplete in core right now, both in
multisite. One is for adding existing users to a site (either from the
network admin or the individual site admin) and the other, added this
cycle, is for the new site admin email (#25348).
In exploring what it would take to allow `wp_dropdown_users()` (and
`wp_dropdown_pages()` in #9864) to use this same method in order to scale,
I realized that a freeform text input as the non-JS part of the UI was not
actually ideal, and in fact, incorrect. If you test some of the patches
I've been periodically putting onto the ticket for progress tracking,
you'll see that I implemented a rough alternate UI, but too late in the
cycle to do proper design and testing.
What I also realized is that the existing usages are actually two
different things, and one of them uses a misleading UI. For a new site
admin email, you can enter any email address and it will create a new user
if that user doesn't already exist. The "autocomplete" in that case is
more of a "prompt" or "suggest" - much like tags. However, when adding an
existing user to a site, the UI really should only allow you to select an
existing user, and not allow for arbitrary input. Essentially, this latter
case should operate much as a select element would. Server-side catches
it, of course, but we should have better UI.
I still want to push forward on approach and aim for early next release
cycle. I'm thinking there are a few aspects:
* What we use as the JS helper for autocomplete. jQuery UI autocomplete
with a custom set of skins, something else? Either way, we should
definitely use our own JS wrapper so that switching libraries or
maintaining shims is a little more future-proofed (see: Masonry).
* The UX and design of said helper.
* Being smart about offering up some initial options to speed things up
(more of a nice-to-have enhancement than a necessity), e.g. 10 users with
the most posts for author selection dropdowns.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/19867#comment:32>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list