https://bugzilla.wikimedia.org/show_bug.cgi?id=25012

Bawolff <bawolff...@gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Created date instead of     |When ordering by created
                   |last edit date              |date, there should be a
                   |                            |method to show creation
                   |                            |date beside the article
                   |                            |like addfirstcategorydate
                   |                            |does with cl_timestamp

--- Comment #5 from Bawolff <bawolff...@gmail.com> 2010-09-22 20:50:31 UTC ---
Changing title to more specific (hopefully I captured that correctly)

I spent a little time investigating this, and there is actually two issues
here, only one of which is DPL's fault:

Issue 1: ( no addcreatedate option )

When DynamicPageList uses order by creation date, it actually orders by page_id
(on the assumption that page ids are sequential and don't get reused, which is
mostly true). The bug is (as far as i understand) that there is no option to
put the date created in front of each article that is output.

Currently the addfirstcategorydate parameter is used, which puts the date the
article was added to the category being listed (cl_timestamp). This generally
works, but occasionally doesn't.

For some reason, all the somolia articles on tawikinews seem to have a
cl_timestamp of sometime in september 2nd, which is making the dates be wrong
on the portal page. Which brings me to issue number 2:

-----

Issue 2 (probably to be split off into another bug as its not a DPL issue):
cl_timestamp is being constantly updated (seemingly each time page is edited,
including null edits but not including action=purge's) in ways it shouldn't be.
(I'll probably file a seperate bug for this.

I really don't understand why that is. Its not like there is any
{{DEFAULTSORT:{{REVISIONID}}}} in the text. I tested on enwikinews and this
does not occur there.


Here's what a did to test this second issue.

*Took a random article from tawikinews: http://ta.wikinews.org/wiki/?curid=959
. This article was from a while ago and had a cl_timestamp for all of its
categories as 9:07 october 23, 2009, presumably from the edit at the same time:
http://ta.wikinews.org/w/index.php?action=historysubmit&diff=2406&oldid=2399

* This was the first weird thing, as based on the edit history, and that as far
as i can tell none of these categories were from templates, the cl_timestamp
should of been set in the edit at
http://ta.wikinews.org/w/index.php?curid=959&diff=prev&oldid=2393 ( oct 22 2009
11:28).

*Then i did action=purge to see if that would affect anythng. It did not

*Then i did a null edit to see if that would change anything. Surprisingly it
did. cl_timestamp of all the categories on that article changed to the current
time! ( sept 22 2009 -
http://ta.wikinews.org/w/api.php?action=query&clprop=timestamp&prop=categories&pageids=959
)

* I did another null edit to see if this was a one time thing (maybe the
unicode normalization of tamil changed in the meanwhile and the sortkeys had to
be updated or something weird like that), however yet again the cl_timestamp
changed

Conclusion, on tawikinews every edit causes the cl_timestamp to be updated.
Expected behaviour is they should only be updated on addition of category,
removal of category, or change of sortkey.

This stumped me for a little while, and then i got thinking about the sortkey,
and checked what it was. It turns out that it was not the full article title
like i expected but only a portion of it (and ended in an invalid unicode
sequence). Looking at the db, sortkey has a max size of 86, so mediawiki must
have been seeing that the current sortkey doesn't = the stored sortkey, so
updating the cl_timestamp, and then the sortkey gets truncated on insert (rinse
and repeat each save)


Probably should of wrote that on a different bug report, but I figured this out
as i was writing this. Will open another bug (assuming the issue still applies
to trunk after all the categorylinks changes)


Tamil folks: as a work around you can add {{DEFAULTSORT:<first 80 bytes, which
is about first 20 letters of page name>}} to new articles, and it may stop this
from happening (it will update the timestamps when you add it though)

-- 
Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
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

Reply via email to