Page MenuHomePhabricator

Special:Protectedpages forgot NULL pr_expiry
Closed, ResolvedPublic


Take a look at
which only lists 12 protected pages. On our wiki, many more pages are protected, however. For instance,
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.

Version: 1.15.x
Severity: normal



Event Timeline

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

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 nor still don't show up in the list.

However, it does for , 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.

show the Main Page? No. Now go to the Main Page. Can you edit it? No.

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,特殊:已保護頁面 gives

Fatal error: Call to a member function getPrefixedUrl() on a non-object in /home/jidanni/phase3/includes/specials/SpecialProtectedpages.php on line 103特殊:已保護頁面 just doesen't reveal the protected pages, and特殊:已保護頁面 acts normally, as it is a newer wiki.

Created attachment 5923
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














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" }


<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

OK, patch appended above.

OK, used cleanupTitles.php to zap the weird name, as per

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