[wp-trac] [WordPress Trac] #10329: sort_by and count_limit options for wp_list_authors

[WordPress Trac]

#10329: sort_by and count_limit options for wp_list_authors
-----------------------------+----------------------------------------------
 Reporter:  takaitra         |       Owner:  westi    
     Type:  feature request  |      Status:  reviewing
 Priority:  normal           |   Milestone:  3.1      
Component:  Template         |     Version:           
 Severity:  normal           |    Keywords:  has-patch
-----------------------------+----------------------------------------------

Comment(by takaitra):

 Replying to [comment:27 t31os_]:
 > I tested the last two patches and they're definately better, but do both
 suffer from a few minor bugs when using particular args in conjunction
 with one another, mincount does not seem to work for me.
 >
 > Try this.
 >
 > {{{
 >
 wp_list_authors('hide_empty=0&optioncount=1&show_fullname=1&feed=feed&number=10&mincount=2');
 > }}}
 >
 The option is "min_count", not "mincount." The above call works for me
 when using the correct option name.
 >
 > One area that could be a problem or even an oversight.
 > {{{
 > if ( $hide_empty || $min_count || $optioncount || $orderby == 'count' )
 {
 > }}}
 > Then 6 lines down, *inside that condition*.
 > {{{
 > if ( !$min_count && !$hide_empty )
 > }}}
 > .. the second condition in some cases can't be met.

 The nested "if" statement you mention switches the inner join to a left
 join in the case that we need to include authors with zero posts. Can you
 explain why this is a problem?

 > I like the patch by Denis(one query total - no offense intended
 takaitra), because it removes any need to call `get_userdata` which eats
 up two queries per iteration.
 >

 I also liked the idea of having as few SQL queries as possible and if you
 look at the earlier patches, you will see that this is the approach I
 took. After performance testing that patch, however, Denis had these
 comments:

  * the group by tends to hinder performance because it introduces a
 unnecessary sort in MySQL; it can be removed entirely
  * the author name logic would actually be better handled by mass-querying
 the usermeta table using the functions from miqrogroove in a separate
 ticket

 So, yes, the latest patch causes more SQL queries initially but 1) it is
 more readable and 2) the get_userdata method caches data so subsequent
 runs of wp_list_authors will be more efficient. I welcome any more
 feedback but I still feel  that my patch is ready for testing by Denis or
 another WP dev.

-- 
Ticket URL: <http://core.trac.wordpress.org/ticket/10329#comment:29>
WordPress Trac <http://core.trac.wordpress.org/>
WordPress blogging software