Last modified: 2011-01-25 00:30:00 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 11487 - Special:Protectedpages forgot NULL pr_expiry
Special:Protectedpages forgot NULL pr_expiry
Status: RESOLVED FIXED
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
1.15.x
All All
: High normal (vote)
: ---
Assigned To: Nobody - You can work on this!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-28 11:54 UTC by Roan Kattouw
Modified: 2011-01-25 00:30 UTC (History)
2 users (show)

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


Attachments
SpecialProtectedpages Forgot NULL (611 bytes, patch)
2009-03-12 06:14 UTC, Dan Jacobson
Details

Description Roan Kattouw 2007-09-28 11:54:33 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.
Comment 1 Dan Jacobson 2007-11-12 04:44:33 UTC
Guessing this is a duplicate of bug 10700

*** This bug has been marked as a duplicate of bug 10700 ***
Comment 2 Brion Vibber 2007-12-03 19:08:44 UTC
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.)
Comment 3 Dan Jacobson 2008-08-22 01:49:07 UTC
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.
Comment 4 Dan Jacobson 2008-08-22 01:56:00 UTC
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"?
Comment 5 Dan Jacobson 2009-03-12 02:56:47 UTC
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.
Comment 6 Dan Jacobson 2009-03-12 03:09:49 UTC
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.
Comment 7 Dan Jacobson 2009-03-12 06:14:24 UTC
Created attachment 5923 [details]
SpecialProtectedpages Forgot NULL
Comment 8 Dan Jacobson 2009-03-12 06:16:13 UTC
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.
Comment 9 Dan Jacobson 2009-03-12 22:28:18 UTC
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.
Comment 10 Roan Kattouw 2009-03-17 15:30:26 UTC
(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?)

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


Navigation
Links