Last modified: 2013-05-10 16:03:36 UTC
r69235 changed the code to add a number of new entries to page_props, but page_props won't actually be updated until each affected page is re-parsed (e.g. with a null edit). A maintenance script to do whatever needs to be done to cause that to happen more quickly would be nice, per discussion in #wikimedia-tech; we have pages on enwiki that haven't been edited for 4 years (see [[Wikipedia:Dusty articles]]).
Removing shell, as it needs to be written first. I'm guessing all pages don't need null editing (ie linkupdates), so maybe there is some specific categories we maybe just need to run it over..?
I think it'd need to be run on all of them (so just use refreshLinks.php ?). Things like displaytitle and defaultsort are stored in pageprops now, which can also appear in transcluded templates, so there's really no way to know what pages need to be purged.
(In reply to comment #1) > Removing shell, as it needs to be written first. FWIW, I was specifically instructed to tag it "shell" on IRC. > I'm guessing all pages don't need null editing (ie linkupdates), so maybe there > is some specific categories we maybe just need to run it over..? Whichever pages are affected by the changes in r69235, i.e. those using {{DEFAULTSORT}}, {{DISPLAYTITLE}}, or double-underscores.
Don't think refreshLinks will actually fix the issue at hand here... Brad, shell is sort of right, but until the script is written (if a new one has to be written), there isn't much point tagging it as such :) If refreshLinks is indeed what needs running, then I apologise for wrongly removing it. Title should be updated as such, and +shell'd again
*** Bug 27553 has been marked as a duplicate of this bug. ***
refreshLinks.php will work, it does a full re-parse and LinksUpdate.
I'm sure nikerabbit couldn't get this to fix some missing category members. Oh well
Moving to component Wikimedia, removing blocker for 1.17wmf1
(In reply to comment #6) > refreshLinks.php will work, it does a full re-parse and LinksUpdate. Won't that take ages to run?
(In reply to comment #9) > (In reply to comment #6) > > refreshLinks.php will work, it does a full re-parse and LinksUpdate. > > Won't that take ages to run? Yes.
*** Bug 21962 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of bug 16112 ***
Not a duplicate of bug 16112, because bug 16112 is just about running "refreshLinks.php --dfn-only", which will not update page_props as described in the above comments and will not update "Categoria:Pages with broken file links", to name just two examples why it would be useful to run refreshlinks.php once.
*** Bug 28628 has been marked as a duplicate of this bug. ***
running it without --dfn-only would take _years_ on en.wp i am being told....
(In reply to comment #15) > running it without --dfn-only would take _years_ on en.wp i am being told.... Yes, unlikely to happen. Clarifying scope and adding as blockers requests for creation of efficient scripts which do only what needed; note that bug 28628 comment 2 contains a proposed solution.
The change was done before 2 years. Since that many pages would changed or reparsed by templates changes, so the page_props and iwlinks table should filled with most of the pages on a wiki. Nobody would write a script and run it on enwiki, due to the long run time, so this gets WONTFIX.
