Page MenuHomePhabricator

updateRestrictions.php not working
Closed, DeclinedPublic

Description

The above URL reports no protected pages, but clearly at least my site's main page is protected.


Version: 1.11.x
Severity: minor
URL: http://radioscanningtw.jidanni.org/index.php?title=Special:Protectedpages&uselang=en

Details

Reference
bz10700

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 9:52 PM
bzimport set Reference to bz10700.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

Run maintenance/updateRestrictions.php.

robchur wrote:

If the updater isn't doing this (and I recall Werdna did add something to do so), then we should add a reminder, at the very least, as for the link table rebuilding when upgrading from pre-1.5 wikis.

OK I just did updateRestrictions.php and even runJobs.php and there's no improvement.

ayg wrote:

(In reply to comment #2)

If the updater isn't doing this (and I recall Werdna did add something to do
so), then we should add a reminder, at the very least, as for the link table
rebuilding when upgrading from pre-1.5 wikis.

It shouldn't be a big issue to do from the updater, should it? You'd have to INSERT SELECT a lot of page rows, but I can't see this getting too far above the hundreds of thousands, say, for any but exceptional cases, and that should be faster than some of the things we do in update.php.

ayg wrote:

(although that's a separate issue)

P.S., mine was never a 1.5 version wiki, I'll have you know.
When 1.5 was invented, I hadn't even heard of Wikimania, where I will see you this year.

(In reply to comment #3)

OK I just did updateRestrictions.php and even runJobs.php and there's no
improvement.

What version of MW are you using? Does specialprotectedpages.php use an odd GROUP BY query? (it once did) I know that acted funky with null pr_expiry values, and there was some inconstancy with that column (null sometimes traded for "infinity".

$ w3m -dump http://radioscanningtw.jidanni.org/index.php?title=Special:Version|grep MediaWiki:

• MediaWiki: 1.10.0

I did not tamper with any of the stock files.

(In reply to comment #8)

$ w3m -dump
http://radioscanningtw.jidanni.org/index.php?title=Special:Version|grep
MediaWiki:

• MediaWiki: 1.10.0

I did not tamper with any of the stock files.

Yes, 1.10 protectedpages does have the odd query. See http://svn.wikimedia.org/viewvc/mediawiki/branches/REL1_10/phase3/includes/SpecialProtectedpages.php?revision=21729&view=markup&sortby=date.
I believe this is resolved when updating to 1.11, though only the developmental alpha is on trunk.

*** This bug has been marked as a duplicate of bug 9882 ***

Still broken in 1.11.0. As above,
http://radioscanningtw.jidanni.org/index.php?title=Special:Protectedpages&uselang=en
says no pages are protected, But the main page,
http://radioscanningtw.jidanni.org/
only lets you see source, as it is protected.

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

Added an 'IGNORE' option on the INSERT in updateRestrictions.php in r28122. This should keep it from crashing if you have conflicting bits in the page.page_restrictions field and the page_restrictions table simultaneously.

Otherwise, updateRestrictions.php should work fine, and does in my test environment. If you can confirm that it still fails when run, please provide copies of your page_restrictions table and page table (at least page_id and page_restrictions columns) and the complete output from the script run.

Marking WORKSFORME since I can't otherwise confirm any problem when it's actually run.

Have un-duped bug 11487.

If you can confirm that it still fails when run

I'll report anything bad I notice on the next regular upgrade.

Anyway, bug 11487 is still very valid as of today and 1.13.