id summary reporter owner description type status priority milestone component version severity resolution keywords cc focuses 38741 Introduce the concept of a large site in order to speed up the Users screen when there are many users johnbillion spacedmonkey "Given a single site install with a high number of users, the Users screen can become very slow due to the nasty query performed by `count_users()`. The result of this query is used to populate the count of users with each role in the role filtering links across the top. {{{ SELECT COUNT(NULLIF(`meta_value` LIKE '%\""administrator\""%', false)), COUNT(NULLIF(`meta_value` LIKE '%\""editor\""%', false)), COUNT(NULLIF(`meta_value` LIKE '%\""author\""%', false)), COUNT(NULLIF(`meta_value` LIKE '%\""contributor\""%', false)), COUNT(NULLIF(`meta_value` LIKE '%\""subscriber\""%', false)), COUNT(NULLIF(`meta_value` = 'a:0:{}', false)), COUNT(*) FROM wp_usermeta WHERE meta_key = 'wp_capabilities' }}} On a site with tens of thousands of users, this SQL query can easily take tens of seconds. Multisite has the concept of a large network (by default, one with > 10,000 users or > 10,000 sites), but single site doesn't have this concept. The query performed by `count_users()` can be skipped entirely. If it is skipped, the list of roles will simply display all available roles and won't display a count next to each role. I think this is a completely acceptable trade-off for such a performance gain on sites with a high number of users." enhancement closed normal 6.0 Users normal fixed has-patch needs-dev-note administration, multisite, performance