Fix page_props and iwlinks: run refreshLinks.php
Closed, DeclinedPublic

Description

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

bzimport added a subscriber: wikibugs-l.
bzimport set Reference to bz27480.
Anomie created this task.Via LegacyFeb 16 2011, 11:56 PM
Reedy added a comment.Via ConduitFeb 17 2011, 12:10 AM

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..?

Bawolff added a comment.Via ConduitFeb 17 2011, 1:50 AM

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.

Anomie added a comment.Via ConduitFeb 17 2011, 1:27 PM

(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.

Reedy added a comment.Via ConduitFeb 17 2011, 6:07 PM

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

TheDJ added a comment.Via ConduitFeb 19 2011, 6:59 PM
  • Bug 27553 has been marked as a duplicate of this bug. ***
bzimport added a comment.Via ConduitFeb 26 2011, 12:32 PM

Bryan.TongMinh wrote:

refreshLinks.php will work, it does a full re-parse and LinksUpdate.

Reedy added a comment.Via ConduitFeb 26 2011, 12:56 PM

I'm sure nikerabbit couldn't get this to fix some missing category members. Oh well

bzimport added a comment.Via ConduitMar 2 2011, 9:48 PM

Bryan.TongMinh wrote:

Moving to component Wikimedia, removing blocker for 1.17wmf1

aaron added a comment.Via ConduitAug 10 2011, 6:42 PM

(In reply to comment #6)

refreshLinks.php will work, it does a full re-parse and LinksUpdate.

Won't that take ages to run?

bzimport added a comment.Via ConduitAug 12 2011, 12:55 PM

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.

Reedy added a comment.Via ConduitSep 14 2011, 9:12 PM
  • Bug 21962 has been marked as a duplicate of this bug. ***
Nemo_bis added a comment.Via ConduitJan 27 2012, 10:33 AM
  • This bug has been marked as a duplicate of bug 16112 ***
UV added a comment.Via ConduitJan 27 2012, 7:44 PM

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.

Reedy added a comment.Via ConduitApr 17 2012, 4:21 PM
  • Bug 28628 has been marked as a duplicate of this bug. ***
Dzahn added a comment.Via ConduitApr 24 2012, 12:15 PM

running it without --dfn-only would take _years_ on en.wp i am being told....

Nemo_bis added a comment.Via ConduitNov 16 2012, 8:17 AM

(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.

duplicatebug added a comment.Via ConduitMay 10 2013, 4:03 PM

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.

Add Comment