[wp-trac] [WordPress Trac] #37128: Introduce helper function `wp_list_sort()`

[WordPress Trac]

#37128: Introduce helper function `wp_list_sort()`
--------------------------------------+------------------
 Reporter:  flixos90                  |       Owner:
     Type:  enhancement               |      Status:  new
 Priority:  normal                    |   Milestone:  4.7
Component:  General                   |     Version:
 Severity:  normal                    |  Resolution:
 Keywords:  has-patch has-unit-tests  |     Focuses:
--------------------------------------+------------------

Comment (by flixos90):

 Replying to [comment:7 jorbin]:
 > In general, core has tended to not add utility functions that it doesn't
 use.  Is there anywhere in core this would make sense right now?  Not
 saying that should keep it out, but I think if core can use it, the case
 for including it is stronger.

 Good point, I was actually planning to look for use-cases earlier. I just
 checked and found several places where using `wp_list_sort()` would make
 sense. We could get rid of the following functions/methods (or at least
 not use them anymore):

 * `_usort_terms_by_name()`
 * `_usort_terms_by_ID()`
 * `_sort_nav_menu_items()`
 * `WP_Customize_Manager::_cmp_priority()`
 * `WP_Customize_Widgets::_sort_name_callback()`

 There might be more, but that's what I found now. So there would indeed be
 a use for the function in Core. I can update another patch later today or
 tomorrow to illustrate what the implementation could look like.

 > One thing that isn't obvious from me just reading the tests and the docs
 is what happens if wp_list_sort is called on an object where `$orderby`
 isn't set on each field?  Where does that fall in the sort?  Seems like
 that is something that should be documented and tested so the code remains
 consistent into the future.

 If the `$orderby` field isn't set on one of the objects/arrays compared,
 the comparison is skipped, basically resulting in an equal comparison. In
 this case the next field compared (if using an array of `$orderby =>
 $order`) will decide. If all comparisons between two objects result in an
 equal check, the whole check will cause an equal result (i.e. return 0).
 Since PHP only does unstable sort, this will unfortunately randomize the
 result. However we can improve this if needed, for example by adding an
 internal `__index` property on each item in the array (and removing it
 again after the comparison) and then fallback to it to maintain the
 original order on an equal comparison.

 > Additionally, what about when you want to do both asc and desc ?  For
 example, alphabetical by title, but reverse chronological? Perhaps there
 should just be a single argument that you pass in that includes both the
 field and the direction?

 In the patch you can do that already: you can specify the `$orderby`
 parameter as an array of (multiple) `$orderby => $order` pairs (in this
 case it will skip the third `$order` parameter). Is that what you meant or
 did I misunderstand you?

--
Ticket URL: <https://core.trac.wordpress.org/ticket/37128#comment:8>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform