Wikimedia Bugzilla is closed!

Splitting off from Bug 25012

Steps to reproduce:
*Add a page to a category and use a really long sortkey (on whats running on wikimedia greater than 86 bytes, for trunk greater than 255 bytes)
*Look up the cl_timestamp using db or api
*do a null edit
*Look up cl_timestamp

Expected behaviour: cl_timestamp should be the same both times (and equal to the first time you edit the page)

Actual behaviour: 
cl_timestamp is the time you did a null edit.


Presumably what happens is mediawiki thinks your sortkey is one thing, it gets truncated when entered into the db, then next time mediawiki thinks the sortkey is the full sortkey, but db thinks its the truncated sortkey, so it assumes the sortkey has changed and updates cl_timestamp. (rinse and repeat each save)


This is particularly noticeable with the non-latin wikinews projects, as the utf-8 encoding of their scripts are bigger, and its more common for the page title to not fit in the sortkey field (presumably with categorylinks table changing sortkey to having a size limit of 255 bytes, this will be alleviated as thats the limit for page names too, however the new sortkey scheme is also supposed to be much bigger for other languages from what i hear so maybe not, anyways it would still a bug when a user manually enters a huge sortkey). These wikinews editions then use DPL, which relies on cl_timestamp not doing this type of thing.


btw there is also an open bug requesting that sortkey changes do not modify cl_timestamp - bug 16287. I think that'd be cool from a DPL prespective, and would solve this issue, but I'm not sure if thats an intended behaviour or not.


p.s. Hopefully i used the depends on/blocks fields correctly as i've never used them before