Last modified: 2011-01-25 00:30:00 UTC
Take a look at http://en.battlestarwiki.org/wiki/Special:Protectedpages which only lists 12 protected pages. On our wiki, many more pages are protected, however. For instance, http://en.battlestarwiki.org/wiki/Template:Podcast_Data was protected at April 19th (as evidenced by its history and Special:Log/protect), but doesn't show up in Special:Protectedpages, nor does any other page that was protected before the 1.9 -> 1.10 upgrade. From reading the code, I gather that Special:Protectedpages only checks the page_restrictions table, but doesn't go the extra backwards-compatible mile to check the page_restrictions field in the page table. Since the protection-checking code also checks for these 'old style' protections, Special:Protectedpages should do so as well.
Guessing this is a duplicate of bug 10700 *** This bug has been marked as a duplicate of bug 10700 ***
Removing duplicate marker. Bug 10700 is described as "updateRestrictions.php doesn't work", which would mean that the process of batch-copying page restrictions information from the page.page_restrictions field to the page_restrictions table via maintenance/updateRestrictions.php fails in some way. This bug is described as "Special:Protectedpages doesn't show pre-1.10 protections", a problem which would be visible on wikis which have old restrictions date and have not run updateRestrictions.php to batch-migrate it. (This batch migration is not necessary for actual page protection and does not affect the ability to edit pages.)
All I know is that I just ran update.php going from 1.12 to 1.13, and the protected Main Page of http://radioscanningtw.jidanni.org/ nor http://taizhongbus.jidanni.org/ still don't show up in the list. However, it does for http://transgender-taiwan.org/ , which is a younger wiki. Therefore I conclude that update.php is still not updating all it should update. There, I just did another php updateRestrictions.php by hand, and it didn't fix anything. Does http://taizhongbus.jidanni.org/index.php?title=特殊:ProtectedPages&uselang=en show the Main Page? No. Now go to the Main Page. Can you edit it? No.
While we are here, do you see lots of red links in http://taizhongbus.jidanni.org/index.php?title=中公:幫助 then why from head, http://taizhongbus.jidanni.org/index.php?title=特殊:WantedPages to tail, http://taizhongbus.jidanni.org/index.php?title=特殊:WantedPages&limit=500&offset=2000 they are not to be found? Is this the same problem, "too old"?
Can't update.php please make the database reflect how the .php files expect it to look? Else forever this Special Page will tell a lie.
Well, as of current SVN, http://taizhongbus.jidanni.org/index.php?title=特殊:已保護頁面 gives Fatal error: Call to a member function getPrefixedUrl() on a non-object in /home/jidanni/phase3/includes/specials/SpecialProtectedpages.php on line 103 http://radioscanningtw.jidanni.org/index.php?title=特殊:已保護頁面 just doesen't reveal the protected pages, and http://transgender-taiwan.org/index.php?title=特殊:已保護頁面 acts normally, as it is a newer wiki.
Created attachment 5923 [details] SpecialProtectedpages Forgot NULL
OK, I think I know what is going on. First let us look at the databases of my three sites: $ for db in transgender taizhongbus radioscanningtw; do echo $db=====; echo "\ SELECT * FROM wiki_page_restrictions;\ SELECT * FROM wiki_page WHERE page_restrictions != '';\ "|mysql --table --default-character-set=latin1 $db; done transgender===== +---------+---------+----------+------------+---------+-----------+-------+ | pr_page | pr_type | pr_level | pr_cascade | pr_user | pr_expiry | pr_id | +---------+---------+----------+------------+---------+-----------+-------+ | 1 | edit | sysop | 0 | NULL | infinity | 5 | | 1 | move | sysop | 0 | NULL | infinity | 6 | +---------+---------+----------+------------+---------+-----------+-------+ taizhongbus===== +---------+---------+---------------+------------+---------+-----------+-------+ | pr_page | pr_type | pr_level | pr_cascade | pr_user | pr_expiry | pr_id | +---------+---------+---------------+------------+---------+-----------+-------+ | 1 | edit | autoconfirmed | 0 | NULL | NULL | 1 | | 1 | move | sysop | 0 | NULL | NULL | 2 | | 1656 | edit | sysop | 0 | NULL | NULL | 3 | | 1656 | move | sysop | 0 | NULL | NULL | 4 | | 2143 | edit | sysop | 1 | NULL | infinity | 5 | | 2143 | move | sysop | 1 | NULL | infinity | 6 | +---------+---------+---------------+------------+---------+-----------+-------+ radioscanningtw===== +---------+---------+----------+------------+---------+-----------+-------+ | pr_page | pr_type | pr_level | pr_cascade | pr_user | pr_expiry | pr_id | +---------+---------+----------+------------+---------+-----------+-------+ | 1657 | edit | sysop | 0 | NULL | NULL | 3 | | 1657 | move | sysop | 0 | NULL | NULL | 4 | | 1672 | edit | sysop | 0 | NULL | NULL | 9 | | 1672 | move | sysop | 0 | NULL | NULL | 10 | +---------+---------+----------+------------+---------+-----------+-------+ OK. Firstly, we notice that if pr_expiry is NULL, the entry gets wrongly ignored by SpecialProtectedtitles.php, whereas is should get reported. Or, update.php should change those NULLs to whatever they should be these days. Also we note that only this one table is involved these days, in contrast to the original bug report. OK, that leaves just two cases. The transgender case, where everything is working fine, and the taizhongbus 2143 case, which crashes MediaWiki as mentioned, unless the user is sysop, when it prints a list item "(36位元組) (全保護, 連鎖) (更改保護)" with no page title. var_dump($row) shows object(stdClass)#93 (8) { ["pr_id"]=> string(1) "5" ["page_namespace"]=> string(1) "1" ["page_title"]=> string(29) "中公討論:Community_Portal" ["page_len"]=> string(2) "36" ["pr_type"]=> string(4) "edit" ["pr_level"]=> string(5) "sysop" ["pr_expiry"]=> string(8) "infinity" ["pr_cascade"]=> string(1) "1" } But http://taizhongbus.jidanni.org/api.php?action=query&prop=info&pageids=2143 shows <page pageid="2143" ns="1" title="討論:中公討論:Community Portal" touched="2007-10-05T04:18:58Z" lastrevid="3989" counter="0" length="36" new="" /> I.e., A doubled "Talk:Project_talk:Community Portal". OK, I will just delete that page, though you might want to add some double checks so it won't crash the program. Hmmm, looks like tough to delete: $ echo 討論:中公討論:Community Portal|php deleteBatch.php Invalid title '討論:中公討論:Community Portal' on line 1 Well, I don't know how to properly delete it then! However, I have found the cause of the bug: function getQueryInfo() { $conds = $this->mConds; # $conds[] = 'pr_expiry>' . $this->mDb->addQuotes( $this->mDb->timestamp() ); The line I commented out never expected pr_expiry to be NULL! I tried to make this into ( (.....) OR (pr_expiry=NULL)) (first | last) View (previous 50) (next 50) (20 | 50 | 100 | 250 | 500) * 首頁 (3,546 bytes) (semi protected) (change) * 模板:B (255 bytes) (fully protected) (change) * (36 bytes) (fully protected, cascading) (change) (first | last) View (previous 50) (next 50) (20 | 50 | 100 | 250 | 500) even the 'page with no valid name' that I don't know how to delete is there. OK, patch appended above.
OK, used cleanupTitles.php to zap the weird name, as per http://article.gmane.org/gmane.science.linguistics.wikipedia.technical/42350 Now all that is left is for you to apply the patch.
(In reply to comment #7) > Created an attachment (id=5923) [details] > SpecialProtectedpages Forgot NULL > Applied in r48489. Since update.php migrates stuff from page.page_restrictions to the page_restrictions table (or is at least supposed to do that), that fixes what's left of this bug. (Does the migration thingy actually work? If so, why do we have code checking for legacy restrictions?)
