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]]).
Version: unspecified
Severity: enhancement
| Status | Subtype | Assigned | Task | ||
|---|---|---|---|---|---|
| Open | Feature | None | T18660 Database table cleanup (tracking) | ||
| Declined | None | T29480 Fix page_props and iwlinks: run refreshLinks.php | |||
| Resolved | None | T30628 cleanup iwlinks table on WMF wikis | |||
| Resolved | None | T32466 clear iwlinks on move over redirect |
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
Bryan.TongMinh wrote:
refreshLinks.php will work, it does a full re-parse and LinksUpdate.
(In reply to comment #6)
refreshLinks.php will work, it does a full re-parse and LinksUpdate.
Won't that take ages to run?
Bryan.TongMinh wrote:
(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.
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.
(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.