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
| Subject | Author | Repo | Branch | Lines +/- | |
|---|---|---|---|---|---|
| CategoryViewer: Introduce cldsort=timestamp | Ladsgroup | mediawiki/core | master | +74 -29 |
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.
