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
SpecialProtectedpages Forgot NULL

Attached:

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=====
+---------+---------+----------+------------+---------+-----------+-------+

+---------+---------+----------+------------+---------+-----------+-------+

+---------+---------+----------+------------+---------+-----------+-------+
taizhongbus=====
+---------+---------+---------------+------------+---------+-----------+-------+

+---------+---------+---------------+------------+---------+-----------+-------+

+---------+---------+---------------+------------+---------+-----------+-------+
radioscanningtw=====
+---------+---------+----------+------------+---------+-----------+-------+

+---------+---------+----------+------------+---------+-----------+-------+

+---------+---------+----------+------------+---------+-----------+-------+

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