Last modified: 2013-09-25 19:23:38 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T56027, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 54027 - sort=descending on list=categorymembers does not reverse types
sort=descending on list=categorymembers does not reverse types
Status: RESOLVED INVALID
Product: MediaWiki
Classification: Unclassified
API (Other open bugs)
1.22.0
All All
: Low enhancement (vote)
: ---
Assigned To: Nobody - You can work on this!
: easy
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-11 19:26 UTC by db [inactive,noenotif]
Modified: 2013-09-25 19:23 UTC (History)
4 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description db [inactive,noenotif] 2013-09-11 19:26:15 UTC
Requesting list=categorymembers with cmdir=descending for a category with page and subcats will give you page first, but cmdir=ascending also gives page as type first. The types should also be reversed, when requesting descending order.
Comment 1 Brad Jorsch 2013-09-11 19:42:45 UTC
Actually, no matter what the sort direction it gives back the types in the order in which they are specified in the cmtype parameter. So if you specify cmtype=subcat|page, you'll get the subcats first.

Is there any particular reason the passed list of types should be reversed when cmdir=descending is given?

At any rate, this would be easy to do if there's a reason to do it. Just pass $queryTypes through array_reverse() if necessary, somewhere around line 97 in the current version of ApiQueryCategoryMembers.php.[1]


 [1]: https://git.wikimedia.org/blob/mediawiki%2Fcore.git/a5502893899a3a71fdfa62f4692dea752bef2eee/includes%2Fapi%2FApiQueryCategoryMembers.php#L97
Comment 2 db [inactive,noenotif] 2013-09-11 19:56:08 UTC
The request was without cmtype, so the default array was used and not reversed. But it looks hard to determine, if the three values was set by client or is the default.
Comment 3 Brion Vibber 2013-09-25 19:23:38 UTC
The order of the grouping isn't really relevant or related to the actual query; you can process or display them in any order you wish.

I'm going to go ahead and close this out as 'invalid'; as noted above if you want the items in a particular order you may ask for them in that order.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links