Last modified: 2011-01-25 01:36:03 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 2919 - Protecting non-existent pages
Protecting non-existent pages
Product: MediaWiki
Classification: Unclassified
Page editing (Other open bugs)
PC All
: Normal enhancement with 21 votes (vote)
: ---
Assigned To: Nobody - You can work on this!
: 3357 5622 (view as bug list)
Depends on: 4145
  Show dependency treegraph
Reported: 2005-07-21 00:05 UTC by Chris Sherlock
Modified: 2011-01-25 01:36 UTC (History)
8 users (show)

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

Implementation details (2.39 KB, application/octet-stream)
2006-12-09 12:19 UTC, Carl Fürstenberg
Updated patch (10.87 KB, patch)
2006-12-09 13:40 UTC, Carl Fürstenberg

Description Chris Sherlock 2005-07-21 00:05:49 UTC
We currently have a situation where pages that are deleted, either through
speedy deletion or via VfD, are being recreated by vandals. Admins must
currently recreate the page, add an appropriate template and then protect the page. 

This means that:

a) the page exists on Wikipedia, and goes downstream into sites that use us for
material, and
b) the page may appear when someone clicks on "Random page". 

Rather than having to recreate the page, I would like to ask for a feature to be
implemented that would allow admins to protect non-existent pages. This would
stop editors from recreating these articles and from causing admins to use this
less than satisfactory work-around.
Comment 1 lɛʁi לערי ריינהארט 2005-10-15 15:07:24 UTC
see also
bug 3627: Special:Contributions lists contributions twice (if new page was created)
Comment 2 lɛʁi לערי ריינהארט 2005-10-15 16:03:15 UTC
please ignore comment #1
> see also
> bug 3627: Special:Contributions lists contributions twice (if new page was
Comment 3 Tom Preuss 2005-10-20 06:41:38 UTC
*** Bug 3357 has been marked as a duplicate of this bug. ***
Comment 4 Melancholie 2006-04-17 18:54:39 UTC
*** Bug 5622 has been marked as a duplicate of this bug. ***
Comment 5 Melancholie 2006-04-17 19:10:00 UTC
To know which lemmas have been detained from creation, a special page would be a 
good idea. This would lower the possibility of misusage of this feature as everyone 
could see what lemma got/is protected unnecessarily (newbies often won't complain if 
a page is protected, but active users will).
Comment 6 Melancholie 2006-04-17 19:13:35 UTC
The page could be called "Special:Lockedlemmas"(?) or maybe better "[[Special:
Comment 7 lɛʁi לערי ריינהארט 2006-04-17 21:08:30 UTC
Bug 3951: Add __NORANDOM__ magic word to force page_random = 0
be usefull if included in {{Gesperrtes Lemma}}) mentioned at bug 5622?
Comment 8 Julian Fleischer 2006-08-06 18:00:33 UTC
Regardless of the problem with blocked lemmas i like the idea of a __NORANDOM__
magic word :)
Comment 9 seahen123 2006-12-08 20:04:52 UTC
Another benefit to this feature would be that we could elect a title to use for
intentionally permanent examples of red links, without fear of vandalism turning
those links blue, analogous to the 555 telephone number or .example TLD.
Comment 10 Carl Fürstenberg 2006-12-09 12:19:37 UTC
Created attachment 2845 [details]
Implementation details

I made this extension now, that I suspect will have the ability to lock down
titles for creation
Comment 11 Rob Church 2006-12-09 12:35:29 UTC
I suggest renaming the extension to something a little more suggestive of the
function and adding some explanatory text to the top of the special page. That
query to create the table on the fly concerns me a little; the database user
might not have permission to create it, and I don't generally agree with
arbitrarily changing the schema in this manner; provide a .sql file and perhaps
a natty little installer script with the rest of the extension files.

When doing the permission check on the special page, make sure you use a
standard OutputPage::permissionRequired() error when the user doesn't have it,
otherwise they won't know what's going on.

The documentation page on needs to lose the .php suffix.
Comment 12 Carl Fürstenberg 2006-12-09 13:40:16 UTC
Created attachment 2846 [details]
Updated patch

Have tried to do what Rob Church said, here's the result :)
Comment 13 Rob Church 2006-12-09 23:47:11 UTC
Avoid setting a UTF8 character set in the SQL, since it's not compatible with
older versions of MySQL.
Comment 14 Aryeh Gregor (not reading bugmail, please e-mail directly) 2006-12-10 02:33:27 UTC
I think this would be best integrated into the core protection code, no? 
Although this is better than nothing, certainly.
Comment 15 Rob Church 2006-12-10 02:34:35 UTC
(In reply to comment #14)
> I think this would be best integrated into the core protection code, no? 

That's the long-term aim, I think; see dependency. In the short term, though, an
extension to do the job might suffice.
Comment 16 Rob Church 2006-12-10 02:35:12 UTC
(Removing patch keywords, since what you've got there is basically an extension,
not a patch against the core code.)
Comment 17 Ligulem 2007-01-31 17:38:36 UTC
On en.wikipedia there is currently a proposal to (ab)use cascading protection to
mimic what's requested in this bug here.


The basic idea (credit: David Levy) is to transclude inexistent page A into page
B and cascade protect B. Non-sysops then can't create page A.
Comment 18 David Levy 2007-01-31 18:03:07 UTC
While a dedicated feature obviously would be preferable, I disagree that this
use of cascading protection constitutes abuse.
Comment 19 Ligulem 2007-01-31 18:49:54 UTC
(In reply to comment #18)
> While a dedicated feature obviously would be preferable, I disagree that this
> use of cascading protection constitutes abuse.

You're right. Sorry. I didn't mean it so seriously :-). Please don't be
offended. Let's call it a workaround.
Comment 20 Ligulem 2007-01-31 19:14:45 UTC
Stupid question: Why must for example return
an error message (the page is inexistent)? Couldn't the relevant checks in
MediaWiki turned into acceptable use cases?
Comment 21 Brion Vibber 2007-02-02 18:30:05 UTC
Because protection only works for pages that exist.

Removing the error message would be rather silly until support for protecting
nonexistent pages is added. :)
Comment 22 Ligulem 2007-02-02 18:56:18 UTC
I got the following explanation (for MediaWiki non-experts like me :-):

> Nonexistent (or deleted) pages currently have no page id.  The
> relevant tables use page id as a key, not page title.

I guess this means quite some work to implement this then. Maybe some trick like
creating a page and mark it as having no content (to connect a page title with a
new id) and then protect that id.

So David's trick to use cascade protection as a workaround seems even more
reasonable then.

Comment 23 Rob Church 2007-02-02 19:06:09 UTC
We could just introduce a separate table that would be checked against when
editing a page that doesn't exist. There's an extension which does this, which
we could integrate into the core with some nice interfaces.
Comment 24 Daniel Cannon (AmiDaniel) 2007-11-04 09:50:35 UTC
Fixed through introduction of cascading protection.
Comment 25 Rob Church 2007-11-04 13:52:29 UTC
(In reply to comment #24)
> Fixed through introduction of cascading protection.

Not an acceptable solution, since it's non-intuitive and doesn't provide appropriate user interface feedback - users should know that they're not allowed to create a page, rather than being told their edits were blocked due to some other transclusion.
Comment 26 Andrew Garrett 2007-12-11 09:52:54 UTC
Implemented in r28385.

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