Last modified: 2009-12-29 11:06:13 UTC
Inspired by Bug 16552 , I'd like to request that $wgCategoryPrefixedDefaultSortkey be set to false for enwikinews, and that maintenance/refreshLinks.php be ran if necessary. (Stupid question: I'm not really familiar with what refreshLinks actually does. Would maintenance/refreshLinks.php cause the cl_timestamp field to be reset for all the category links and thus cause all the DPL's sorted by categoryadd date to be reset, if so that'd be a bad thing as wikinews is heavily dependent on DPL's, so I'm only requesting this if that wouldn't happen.) Community discussion at http://en.wikinews.org/wiki/Wikinews:Water_cooler/technical#having_pages_in_category_default_sorted_by_.7B.7BPAGENAME.7D.7D_not_.7B.7BFULLPAGENAME.7D.7D ( permalink: http://en.wikinews.org/w/index.php?title=Wikinews:Water_cooler/technical&oldid=840276#Votes ) Thanks, [[n:user:Bawolff]]
(In reply to comment #0) > Inspired by Bug 16552 , I'd like to request that > $wgCategoryPrefixedDefaultSortkey be set to false for enwikinews, and that > maintenance/refreshLinks.php be ran if necessary. (Stupid question: I'm not > really familiar with what refreshLinks actually does. Would > maintenance/refreshLinks.php cause the cl_timestamp field to be reset for all > the category links and thus cause all the DPL's sorted by categoryadd date to > be reset, if so that'd be a bad thing as wikinews is heavily dependent on > DPL's, so I'm only requesting this if that wouldn't happen.) > I believe it would reset cl_timestamp for all category links whose sortkeys are updated, but that would also happen when a page containing such category links is updated. I repeat: if I set this setting, the cl_timestamp for all categorylinks whose sortkey changes will be reset, either immediately because I run refreshLinks or over time because pages are edited. I didn't do anything just yet because of the concerns mentioned above; if you're aware of these and want me to continue regardless, please leave a comment.
If it only resets cl_timestamp of things _not_ in the main namespace, it is not really an issue. If it resets the cl_timestamp for pages in the main namespace, this would be a very very very very very very very Bad Thing. If in doubt, don't do it.
(In reply to comment #2) > If it only resets cl_timestamp of things _not_ in the main namespace, it is not > really an issue. If it resets the cl_timestamp for pages in the main namespace, > this would be a very very very very very very very Bad Thing. If in doubt, > don't do it. > It shouldn't affect the main namespace. I'll test this locally, and if it turns out to be correct, I'll set the var and run the script tonight (CET).
I've added the config var and started the script at 13:42 UTC (nearly an hour ago). It'll probably need another four hours or so to finish, after which I'll close this bug.
(In reply to comment #4) > I've added the config var and started the script at 13:42 UTC (nearly an hour > ago). It'll probably need another four hours or so to finish, after which I'll > close this bug. > Script has finished, everything should be good now.
