Last modified: 2010-05-15 15:59:43 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T12700, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 10700 - updateRestrictions.php not working
updateRestrictions.php not working
Status: RESOLVED WORKSFORME
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.11.x
All All
: Low minor (vote)
: ---
Assigned To: Nobody - You can work on this!
http://radioscanningtw.jidanni.org/in...
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-07-25 22:23 UTC by Dan Jacobson
Modified: 2010-05-15 15:59 UTC (History)
1 user (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments

Description Dan Jacobson 2007-07-25 22:23:47 UTC
The above URL reports no protected pages, but clearly at least my site's main page is protected.
Comment 1 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-25 22:32:51 UTC
Run maintenance/updateRestrictions.php.
Comment 2 Rob Church 2007-07-25 22:39:38 UTC
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.
Comment 3 Dan Jacobson 2007-07-25 22:44:26 UTC
OK I just did  updateRestrictions.php and even runJobs.php and there's no improvement.
Comment 4 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-25 22:50:36 UTC
(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.
Comment 5 Aryeh Gregor (not reading bugmail, please e-mail directly) 2007-07-25 22:50:46 UTC
(although that's a separate issue)
Comment 6 Dan Jacobson 2007-07-25 22:55:45 UTC
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.
Comment 7 Aaron Schulz 2007-07-25 23:34:00 UTC
(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".
Comment 8 Dan Jacobson 2007-07-25 23:45:03 UTC
$ 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.
Comment 9 Aaron Schulz 2007-07-26 03:05:13 UTC
(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.
Comment 10 Aaron Schulz 2007-09-30 21:00:57 UTC

*** This bug has been marked as a duplicate of bug 9882 ***
Comment 11 Dan Jacobson 2007-11-12 04:43:54 UTC
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.


Comment 12 Dan Jacobson 2007-11-12 04:44:33 UTC
*** Bug 11487 has been marked as a duplicate of this bug. ***
Comment 13 Brion Vibber 2007-12-03 19:19:50 UTC
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.
Comment 14 Dan Jacobson 2007-12-04 03:26:12 UTC
> If you can confirm that it still fails when run
I'll report anything bad I notice on the next regular upgrade.
Comment 15 Dan Jacobson 2008-09-06 19:12:53 UTC
Anyway, bug 11487 is still very valid as of today and 1.13.

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links