https://bugzilla.wikimedia.org/show_bug.cgi?id=25254
Summary: Using a sortkey longer than the db field causes
cl_timestamp to be updated on every page save
(including null edits) even if the edit did not touch
the category
Product: MediaWiki
Version: 1.17-svn
Platform: All
OS/Version: All
Status: NEW
Severity: normal
Priority: Normal
Component: Categories
AssignedTo: wikibugs-l@lists.wikimedia.org
ReportedBy: bawolff...@gmail.com
CC: amgine.sae...@gmail.com
Depends on: 16287
Blocks: 16602
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
--
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are on the CC list for the bug.
_______________________________________________
Wikibugs-l mailing list
Wikibugs-l@lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
