Last modified: 2007-03-19 01:34:58 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T4171, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 2171 - Query page to list protected pages
Query page to list protected pages
Product: MediaWiki
Classification: Unclassified
Special pages (Other open bugs)
All All
: Normal enhancement with 17 votes (vote)
: ---
Assigned To: Rotem Liss
: 2608 4577 6211 7575 (view as bug list)
Depends on: 4145
Blocks: 9326
  Show dependency treegraph
Reported: 2005-05-14 15:17 UTC by Roybb95
Modified: 2007-03-19 01:34 UTC (History)
6 users (show)

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

Patch (3.58 KB, patch)
2006-10-06 16:46 UTC, Rotem Liss

Description Roybb95 2005-05-14 15:17:09 UTC
It would be very usefull if there was special page with a list of all protected
Comment 1 Ævar Arnfjörð Bjarmason 2005-05-14 15:59:13 UTC
Doing this with the current schema (1.4 and 1.5) is obscenely slow, the
(?:page|cur)_restrictions wasn't designed to be mass searched.

On the 2005-03-09 en.wikipedia dump:
mysql> SELECT cur_title, cur_restrictions FROM cur WHERE cur_restrictions LIKE
297 rows in set (5 min 44.24 sec)
Comment 2 Brion Vibber 2005-05-15 01:27:28 UTC
Would need to add an index on that field, I suppose.

An alternative is splitting the protection to a linked table (perhaps useful for getting at the 
multiple settings in a clearer fashion than the blob we have now).
Comment 3 Brion Vibber 2005-06-29 17:43:55 UTC
*** Bug 2608 has been marked as a duplicate of this bug. ***
Comment 4 Borgx 2005-12-02 00:34:54 UTC
is there any progress? 
Comment 5 Filip Maljkovic [Dungodung] 2005-12-02 12:52:00 UTC
A friend of mine made the special page and it looks good IMO (see The only
problem Avar suggested to me on the IRC is that the page doesn't support
caching, but I think that's not a hard thing to do. Funny thing - I didn't know
this bug even existed, so I asked Avar to make it. Now there really is a feature
request. Great.
Comment 6 Filip Maljkovic [Dungodung] 2006-01-12 13:25:28 UTC
*** Bug 4577 has been marked as a duplicate of this bug. ***
Comment 7 p_simoons 2006-01-12 13:40:16 UTC
As reported on ANI, three admins work daily to keep the manually-generated
[[Wikipedia:Protected page]] up to date with the current situation. Automation
would apparently be a useful timesaver.
Comment 8 Brion Vibber 2006-06-05 19:52:24 UTC
*** Bug 6211 has been marked as a duplicate of this bug. ***
Comment 9 Max Semenik 2006-06-06 20:24:32 UTC
And what about my code from Bug 6211? It does not search in page_restrictions, only 
checks length. Is it faster? Can anyone with dumps check?
Comment 10 Darkoneko 2006-06-13 10:40:39 UTC
Now, the same could be asked for the semi-protected pages ;)

If there's a problem about slowness, IMO it's still useful even if the page is
only upgraded every few days or so
Comment 11 Rotem Liss 2006-10-06 16:46:13 UTC
Created attachment 2463 [details]

This is a complete patch, ready for commiting. I used the following query:

SELECT 'Protectedpages' AS type, page_namespace AS namespace, page_title AS
title, page_restrictions AS restrictions FROM $page WHERE page_restrictions <>
'' AND page_namespace <> $mediawiki

($page = 'page' normally, $mediawiki = NS_MEDIAWIKI)

and marked it as expensive, because page_restrictions is not (yet?) marked as
index. Running the query on a recent dump of dewiki (couldn't set up enwiki,
too slow to add all these rows) on my computer resulted:

14919 rows in set (8.29 sec)

It seems to be generally OK (my computer is a bit slow - a former test resulted
about 7 seconds), but definitely expensive. For comparison, running the query
of Special:Shortpages on dewiki resulted:

482777 rows in set (6.19 sec)

Two questions:
1. Should I define the caching in some other place?
2. Is it the correct query, or it should be changed somehow?

Comment 12 Aaron Schulz 2006-10-06 18:43:48 UTC
I currently run the bot that has maintains en wikipedia's list of protected
pages for while now. Such a MW feature might be useful, but it will need
protection type filtering for:
*Semi-protected (edit)
*Full-protected (edit)
*Full-protected (move only)

Also, things like redirects and deleted pages (this one might be tricky) would
need to be filtered out. Deleted pages used to *flood* WP:PP until I added a
regexp xml filter check for each page (kind of tedious though) which also checks
for redirects while its at it.

Without these two sets of filters (protection type and redir/DP type) such a
page will be of very limited use on a large wikipedia site, likely not worth
being expensive. However this would be an effective replacement for WP:PP on
smaller wiki sites.
Comment 13 Rotem Liss 2006-10-14 11:35:07 UTC
*** Bug 7575 has been marked as a duplicate of this bug. ***
Comment 14 Christopher Hagar 2006-10-14 19:19:23 UTC
As mentioned here,, this
page should perhaps be restricted to sysops, at least for semi-protected pages.
Comment 15 Aaron Schulz 2007-01-10 23:59:20 UTC
Perhaps a page_len column or a joint query would help to allow filtering which
pages show on the list to avoid deleted pages from drowing all out.
Comment 16 Rotem Liss 2007-01-11 16:00:30 UTC
Comment on attachment 2463 [details]

page.page_restrictions is no longer used (the table page_restrictions is used
instead). A new patch should be created.
Comment 17 Rotem Liss 2007-01-22 15:10:21 UTC
Werdna added a special page, Special:Protectedpages, in r19561.

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