Last modified: 2007-03-19 01:34:58 UTC
It would be very usefull if there was special page with a list of all protected
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)
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).
*** Bug 2608 has been marked as a duplicate of this bug. ***
is there any progress?
A friend of mine made the special page and it looks good IMO (see
http://conversion.vikimedija.org/index.php/Special:Protectedpages). 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
*** Bug 4577 has been marked as a duplicate of this bug. ***
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.
*** Bug 6211 has been marked as a duplicate of this bug. ***
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?
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
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)
1. Should I define the caching in some other place?
2. Is it the correct query, or it should be changed somehow?
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:
*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.
*** Bug 7575 has been marked as a duplicate of this bug. ***
As mentioned here,
page should perhaps be restricted to sysops, at least for semi-protected pages.
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 on attachment 2463 [details]
page.page_restrictions is no longer used (the table page_restrictions is used
instead). A new patch should be created.
Werdna added a special page, Special:Protectedpages, in r19561.