Page MenuHomePhabricator

When ordering by created date, there should be a method to show creation date beside the article like addfirstcategorydate does with cl_timestamp
Open, MediumPublic

Description

<DynamicPageList>
category=published
category=Somalia
count=10
suppresserrors=true
ordermethod=created
addfirstcategorydate=true
</DynamicPageList>

The above code returns list of articles with date but whenever there is a change in the article it displays the last edited date along with the title. But We need to display articles created date. Kindly help us to fix it.

Regards
Mohamed Mahir


Version: unspecified
Severity: normal
URL: http://ta.wikinews.org

Details

Reference
bz25012

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 11:11 PM
bzimport set Reference to bz25012.
bzimport added a subscriber: Unknown Object (MLST).

Just as a note, traditionally (As in what enwikinews does) uses sorting by the date added to category published, not the create date.

The code you presented above should order them by create date, but show the date that the article was added to category:Published. There is currently no way to show the create date instead of date added to first category.

Do you have an example page where its showing last edit date instead of date added to category published?

Thanks for your reply.

Yes we want published date.

Other active contributor tells, it happen whenever there is a change in the corresponding templates.

For example, we have a portal:somalia at http://ta.wikinews.org/wiki/வலைவாசல்:சோமாலியா

and we have templates:somalia at http://ta.wikinews.org/wiki/வார்ப்புரு:சோமாலியா

please see the dates for all the articles in the template are changed to 2nd september. But if u check the articles the actual date is different.

Please help us to fix.

Thanks
Mahir

Thanks for your reply.

Yes we want published date.

Other active contributor tells, it happen whenever there is a change in the corresponding templates.

For example, we have a portal:somalia at http://ta.wikinews.org/wiki/வலைவாசல்:சோமாலியா

and we have templates:somalia at http://ta.wikinews.org/wiki/வார்ப்புரு:சோமாலியா

please see the dates for all the articles in the template are changed to 2nd september. But if u check the articles the actual date is different.

Please help us to fix.

Thanks
Mahir

kstharan wrote:

For example, the following article was published on April 15, 2010, and modified yesterday.
http://ta.wikinews.org/wiki/சோமாலிய_வானொலிகளில்_பாடல்கள்_ஒலிபரப்புவதற்கு_போராளிகள்_தடை_விதிப்பு
The template shows this article as new.

Thanks for the help.
Regards
Kanags

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

*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)

Note: issue 2 was split off into Bug 25254

kstharan wrote:

Thanks Bawolff. I will try your DEFAULTSORT suggestion to the new articles.

  • Bug 30852 has been marked as a duplicate of this bug. ***