We collect the timestamp of categorization (using cl_timestamp) and even index on it (cl_timestamp_id) but the category page doesn't allow us to order the list based on that value. This can be quite helpful in maintenance categories (e.g. "show me pages that have been marked for deletion for long time) and many other usecases. We can simply add a drop down of order by on the top of the list.
Description
Details
Related Objects
Event Timeline
Change #1319917 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup):
[mediawiki/core@master] CategoryViewer: Introduce cldsort=timestamp
Works like a charm locally:
Of course, it's missing the UI parts but that'd be a pretty good start
Change #1319917 merged by jenkins-bot:
[mediawiki/core@master] CategoryViewer: Introduce cldsort=timestamp
@Ladsgroup is this accurate:
Category pages will soon support sorting entries by the time they were added to a category. This will make it easier to find recently or long-standing categorized pages. It will also improve workflows for maintenance categories such as deletion backlogs and other time-based review tasks.
I am also assuming it is ready to be announced?
Overall it's good but we have already deployed it already (there is no UI yet though). We can also mention it that using cldsort=timestamp argument in category view would sort them.
Thanks a lot for this. But does it fully work, or we need to wait for cache update? I'm asking because every page added before Janyary 1, 2025 appears as March 7, 2025. Thank you.
It does work and no need for a cache invalidation. The problem is that all categorylinks rows were reset in early 2025 (I don't know exactly why) but anything added before that date will be lumped together into that specific date (which is different from wiki to wiki). But that really shouldn't matter for maintenance categories.
We don't keep backups nor binlogs for that long so the only option is a time machine :D
In this case, I suggest to change "March 7, 2025" to "Before March 8, 2025". I mean, if it is possible to know such a date for every wikisite.
We can make a tiny change the first date in the category would say it's that date or before (so "March 8, 2025 or before"). It's a bit complex to implement but doable.
The code has an option to flip the order, it's when until is called but when I try it, it doesn't work. I'm sure I can add a simple order option to gui too. Shouldn't be hard. In the meantime, you can use pageuntil=Very-far-future-date to get the most recent ones: https://en.wikipedia.org/w/index.php?title=Category:2026_deaths&cldsort=timestamp&pageuntil=2027-01-10+03%3A32%3A40#mw-pages
But it is not the first date. There are single pages even from year after year before, since at least 2008, and the dates fit their history. For 2025 it doesn't.
Is it possible to add a magic word in the category description to make it default to date sorting, similar to the way something like __NOGALLERY__ works? I could see this being useful for many maintenance categories where the name of the item really isn't important.
I like the idea but when I thought about it, I'm not so sure. Two reasons: Once we introduce it, we need to maintain it forever since this will be part of wikitext which is much harder to change than anything else. Second is that we would also need to introduce another word for changing the default order ("most recent first", ...) and I can imagine that in the future we could introduce other ways of ordering entries in a category (page size, ...) and it would open a pandora box that would be pretty hard to close.
As the "second best thing", we can update https://en.wikipedia.org/wiki/Template:CSD-categories to link to these categories with cldsort set.
As the one that worked a lot with maintenance categories, I like this suggestion very much either. So, because of what you said, here is the alternative solution: {{CATEGORYSORT:TIMESTAMP}}. This will easily allow to add another order types in the future, if needed.
How does this work on Commons - can it sort by the photograph date? Also, what happens if pages are bulk-removed and then re-added to a category?
It can't and it would be really hard to implement it but you can have the date categorization as a "good enough" proxy . And yes, removing and re-adding resets the date. It's not perfect but better than nothing.
Change #1340051 had a related patch set uploaded (by Ladsgroup; author: Ladsgroup-claude):
[mediawiki/core@master] [WIP] CategoryViewer: Add CATEGORYSORT parser function and reverse ordering
The above patch implements a magic word called CATEGORYSORT. You can set it like {{CATEGORYSORT:RTIMESTAMP}} (newest first) or {{CATEGORYSORT:RTIMESTAMP}} (oldest first). Any comments?
Change #1340051 merged by jenkins-bot:
[mediawiki/core@master] CategoryViewer: Add CATEGORYSORT parser function and reverse ordering
For anyone confused same as me, it is {{CATEGORYSORT:TIMESTAMP}} for newest and {{CATEGORYSORT:RTIMESTAMP}} for oldest first.
I like this as an option that users can turn on when it's useful to them, but having it as an arbitrarily-implemented default in some categories but not others will probably lead to confusion. It sounds more like a user preference for readers than it does a magic word that editors that can force on everyone accessing the category.
The main point of this magic word is for categories such as copyright violations, speedy deletions, and other backlog lists. To make sure pages that have been waiting the longest, get handled first. This is quite useful in such cases and actually any other sorting mechanism makes little sense (why would anyone want to check list of copyright violation in alphabetical order?). For example drafts waiting to be reviewed https://en.wikipedia.org/wiki/Category:Draft_articles?cldsort=timestamp
I'm not sure using it on random categories make sense (beside some novelty or just checking what has been added to a category recently).
Something that is a bit of a gray area is that now you can simply do this: https://en.wikipedia.org/wiki/Category:All_articles_with_a_promotional_tone?cldsort=timestamp instead of creating https://en.wikipedia.org/wiki/Category:Articles_with_a_promotional_tone_from_March_2025 and so on. But I leave that to the community to decide whether they want it that way or not.
I’ll add my metaphorical +2 to it being very useful as a magic word for any tracking categories (which in many cases aren’t separated by month or year at all). The only unfortunate part is that it’s not as useful as monthly/yearly categories as of now because of the missing data issue (but hopefully in 10 years or so some of the backlog disappears enough that it stops mattering :-)).
I'm missing the context here then - where was this proposed on-wiki? Only using this in maintenance categories sounds reasonable to me - is there a way that could be enforced? I'm more worried about where it might be randomly applied to content categories.
You could say exactly the same thing about __HIDDENCAT__ as well. If people decide to add it, you can revert it. Wikis might decide in which way they want to use it. Some wikis might be liberal about it, some not. I'm just providing the feature.
It’s the same as with any other magic word: you can currently (and for a long time unless we retire CirrusSearch) track it down by searching for insource:"CATEGORYSORT:" insource:/CATEGORYSORT:R?TIMESTAMP/ prefix:category:. Wikis can enforce this sort of thing via bots if they so choose. I think if we allow __NOTOC__ and __NOEDITSECTION__ to be readily available in the visual editor of all places (for some reason!), I don’t see how having this keyword would be any more confusing to have.
HIDDENCAT, NOTOC, and NOEDITSECTION are all very different key words since they are immediately obvious in their impact in a way that CATEGORYSORT is not. We don't explain how we're sorting categories, so having some randomly ordering them by date will confuse people. I like the original idea of having this as a drop-down menu choice.
The huwiki community is in fact very much interested to have this function, preferably as a drop-down menu option (see this example ambox implemented on a content category). In my opinion the sorting would be useful not only for the maintenance categories, but for some content categories as well, e.g. to monitor recently categorised living people. Ping @binbot.
I think one way to reduce the confusion is to wrap the magic word with a template the beside adding the magic word, explains also what's going on. This is exactly how hidden cat is done: https://en.wikipedia.org/wiki/Template:Hidden_category
So I created https://en.wikipedia.org/wiki/Template:Catsort-by-reverse-timestamp and https://en.wikipedia.org/wiki/Template:Catsort-by-timestamp
@Ladsgroup: if I change the DEFAULTSORT of a redirect page, the category shows "18 September 2026". Is it the expected behavior?
For instance:
- I changed a DEFAULTSORT in https://fr.wikipedia.org/w/index.php?title=Frank_Lundy&diff=prev&oldid=239617226
- Now Frank Lundy appears below "18 September 2026" in https://fr.wikipedia.org/w/index.php?title=Cat%C3%A9gorie:Redirection_de_pr%C3%A9caution&cldsort=timestamp&pagefrom=2026-02-17+13%3A33%3A34#mw-pages
I like this approach - the pull-down menu for users would be better, but this is a reasonable middle-ground. Is there a bot that replaces the direct use of the key word with a template that could also cover this new case?
It does not work by transclusion? I've just tried to add it to Template:Tracking Category.
It means changing the category sortkey resets the timestamp, I take a look and fix it.
It should work, I'm not seeing your edit on the template. Preview doesn't work though. You need to save it.
It should work, I'm not seeing your edit on the template. Preview doesn't work though. You need to save it.
I did.
https://en.wikipedia.org/w/index.php?title=Template:Tracking_category&action=history
if you mean in another wiki. I think you probably need to do an empty edit to get it to register. it's a bit weird. I don't know why our caching here is so sticky but transclusion works, as you can see in https://en.wikipedia.org/wiki/Special:WhatLinksHere?target=Template%3ACatsort-by-timestamp&namespace=&hidelinks=1&hideredirs=1&limit=50
We need to announce this but the new feature now:
There is now a new magic word called {{CATEGORYSORT:TIMESTAMP}} and {{CATEGORYSORT:RTIMESTAMP}}. They change the default sorting of categories to be based on timestamp of categorization.
@Ladsgroup: thanks to your work in this Phabricator task, I have created in the French Wikipedia:
- the template "Ordre d'affichage" (in English, it means "Display order") which displays three buttons to dynamically choose the display order of elements in a category
- for instance, you can see the three buttons at the bottom of the description of this category.
@Ladsgroup well, this is not limited to redirect pages. This is applicable to basic articles, for instance:
- someone changed a DEFAULTSORT in https://fr.wikipedia.org/w/index.php?title=%C5%9Eemsettin_%C3%9Cnl%C3%BC&diff=prev&oldid=239879968
- now the article appears below "28 September 2026" in https://fr.wikipedia.org/w/index.php?title=Cat%C3%A9gorie:Article_%C3%A0_wikifier/Liste_compl%C3%A8te&cldsort=timestamp&cldorder=desc
Yeah, changing the sort key resets the timestamp (regardless of how) and that seems to be intentional. We can change it but I would need some user feedback before I can implement it.
Was this timestamp variable exposed anywhere before to warrant user feedback on this? If not, seems like most people would probably not care either way. The only way I can imagine it mattering is that if it affects category change RC items but I’m not sure it does, since it’s not changing relationship to the category?
Are there plans to make {{CATEGORYSORT:}} work when previewing the page? This certainly wouldn't be easy to implement (I know from experience; I've developed an extension in which CategoryViewer behavior is similarly affected by magic words), but it would be good for UX.
Well, I created Template:Display order in the English Wikipedia, too. For instance, you can see the three buttons in the description of Category:Open Wikipedia bot requests for approval.
I created https://www.wikidata.org/wiki/Q141551445 in a couple of wikis. For some it makes sense to change the default as well.
It would be good to get this documented at https://www.mediawiki.org/wiki/Help:Categories, too.
At Enwiki, user:PrimeHunter has helpfully documented it at https://en.wikipedia.org/wiki/Help:Category#Sort_order which might be re-usable/adaptable?
(P.s. Thank you to AntiCompositeNumber for the existing new documentation in mw:Help:Magic_words)
I added https://www.mediawiki.org/wiki/Help:Categories#Sorting_a_category feel free to edit mercilessly.
I think this is done now.
I think this should be eventually re-considered if we want people to drop custom sorting keys based on dates. Right now if I edit some module that previously added them, as a result of my edit all of them would be displayed as being categorised on the same day, while my intention would’ve been to display initial categorisation date. I was asked by someone if we could drop date-based keys in one very frequently used module and my answer was no based on this detail.
