Last modified: 2009-01-12 14:27:47 UTC
The API is outputting that a particular page is protected when the protection log (and reality) indicate otherwise. This may be a Wikimedia issue and it may not be related to the API at all, but I filed it under MediaWiki / API anyway. The API query is: http://en.wikipedia.org/w/api.php?action=query&prop=info&inprop=protection&titles=1755%20Lisbon%20earthquake The protection log for the given title is: http://en.wikipedia.org/w/index.php?title=Special:Log&page=1755_Lisbon_earthquake So perhaps one of the tables contains bad rows? Or the API has a glitch? The output from the API looks rather unusual: <?xml version="1.0"?> <api> <query> <pages> <page pageid="352339" ns="0" title="1755 Lisbon earthquake" touched="2008-12-13T10:06:03Z" lastrevid="257482439" counter="1" length="21025"> <protection> <pr type="edit" level="" expiry="infinity" /> <pr type="move" level="" expiry="infinity" /> <pr type="move" level="" expiry="infinity" /> <pr type="edit" level="" expiry="infinity" /> </protection> </page> </pages> </query> </api>
(In reply to comment #0) > So perhaps one of the tables contains bad rows? Or the API has a glitch? The > output from the API looks rather unusual: > I think so. Could someone with toolserver access verify this with the following query (on enwiki)? SELECT pr_page, pr_type, pr_level, pr_expiry, pr_cascade FROM page_restrictions WHERE pr_page=352339;
mzmcbride@nightshade:~$ sql enwiki_p mysql> SELECT pr_page, pr_type, pr_level, pr_expiry, pr_cascade FROM page_restrictions -> WHERE pr_page=352339; +---------+---------+----------+-----------+------------+ | pr_page | pr_type | pr_level | pr_expiry | pr_cascade | +---------+---------+----------+-----------+------------+ | 352339 | edit | | infinity | 0 | | 352339 | move | | infinity | 0 | +---------+---------+----------+-----------+------------+ 2 rows in set (0.00 sec)
(In reply to comment #2) > mzmcbride@nightshade:~$ sql enwiki_p > > mysql> SELECT pr_page, pr_type, pr_level, pr_expiry, pr_cascade FROM > page_restrictions > -> WHERE pr_page=352339; > +---------+---------+----------+-----------+------------+ > | pr_page | pr_type | pr_level | pr_expiry | pr_cascade | > +---------+---------+----------+-----------+------------+ > | 352339 | edit | | infinity | 0 | > | 352339 | move | | infinity | 0 | > +---------+---------+----------+-----------+------------+ > 2 rows in set (0.00 sec) > Received through pastebin: sql enwiki_p mysql> SELECT COUNT(*) FROM page_restrictions WHERE pr_level=''; +----------+ | COUNT(*) | +----------+ | 3414 | +----------+ 1 row in set (0.99 sec) mysql> SELECT page_restrictions FROM page WHERE page_id=352339; +-------------------+ | page_restrictions | +-------------------+ | move=:edit= | +-------------------+ 1 row in set (0.00 sec) mysql>
(In reply to comment #3) > mysql> SELECT COUNT(*) FROM page_restrictions WHERE pr_level=''; > +----------+ > | COUNT(*) | > +----------+ > | 3414 | > +----------+ > 1 row in set (0.99 sec) So there are probably 1707 pages with corrupted protections like these. > mysql> SELECT page_restrictions FROM page WHERE page_id=352339; > +-------------------+ > | page_restrictions | > +-------------------+ > | move=:edit= | > +-------------------+ > 1 row in set (0.00 sec) This is also corrupted, and causes the other two entries in the API output.
Changing summary and component accordingly.
"move=:edit=" is perfectly legit in page.page_restrictions, and is just the old way of indicating that move and edit are both not restricted. If the API is misinterpreting them, that's probably wrong. The page_restrictions table entries, however, do seem bogus. If there's remaining migration code that's mis-migrating these, it needs to be fixed not to save the extra entries. I'm currently running a batch job to clear them out...
(In reply to comment #6) > "move=:edit=" is perfectly legit in page.page_restrictions, and is just the old > way of indicating that move and edit are both not restricted. If the API is > misinterpreting them, that's probably wrong. > OK, I'll fix that.
(In reply to comment #6) > "move=:edit=" is perfectly legit in page.page_restrictions, and is just the old > way of indicating that move and edit are both not restricted. If the API is > misinterpreting them, that's probably wrong. > > The page_restrictions table entries, however, do seem bogus. If there's > remaining migration code that's mis-migrating these, it needs to be fixed not > to save the extra entries. > > I'm currently running a batch job to clear them out... > Is this done?
Yes, the first part was done (running the maintenance script on WMF's tables). From the Toolserver sql enwiki_p today: mysql> SELECT COUNT(*) FROM page_restrictions WHERE pr_level=''; +----------+ | COUNT(*) | +----------+ | 0 | +----------+ 1 row in set (0.02 sec) The second part is still (as far as I'm aware) unresolved. Just waiting on Roan to commit some pretty code. :-)
(In reply to comment #9) > The second part is still (as far as I'm aware) unresolved. Just waiting on Roan > to commit some pretty code. :-) > Done in r45675.