Last modified: 2011-03-13 18:05:28 UTC
The DPL (aka intersection) extension that wikinews uses, uses the categoryadd timestamp to order articles, which for the most part works great. However on rare occasions the categoryadd timestamp can get reset (See related bug 20243 and bug 16287). Most commonly this is as a result of page blanking vandalism, or changing the sortkey of a category. This causes problems for us (for example: article from 2 years ago being listed as most recent published = bad thing). I'd like to make a feature request that the api have some method of changing the categoryadd timestamps. Something like: api.php?action=resetcategoryadd&title=Article_Name&category=Category:Category_Name&setdate=new_date Assuming that the person was an admin, and that the article in question had a pre-existing link to the category in question, that would set the categoryadd timestamp for the category in question to the date specified. Thus in the rare case when a categoryadd date gets reset, we would have some method of fixing it. Thanks, Bawolff
This would allow users to fiddle with MediaWiki's internals, which may not be desirable. On the other hand, I believe that cl_timestamp was specifically added for DPL?
The cl_timestamp field has a clear definition that the software lives up to. If you don't like that definition, you should ask for the field to be redefined or for a new field to be added, not for a way to allow everyone to put random crap into the field so it loses all meaning.
Since most of the problems being experienced are a result of a vandal blanking a page, and then getting subsequently reverted, would the following scheme work: If you have two revisions of the same page (one being the current revision, the other being some previous revision), which both have the exact same categories, make it possible for admins to set the cl_timestamp to the revision date of the earlier revision. That way there isn't just random garbage in the field, its value is a value that would have been valid at one point (In essence admins would be able to revert the field to a previous value if the categories are the same between the two revisions in question). Or is that still not in line with the definition of the field? Thanks for your consideration.
