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
        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:
------- 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

Reply via email to