Last modified: 2011-01-25 01:36:03 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.
see also bug 3627: Special:Contributions lists contributions twice (if new page was created)
please ignore comment #1 > see also > bug 3627: Special:Contributions lists contributions twice (if new page was created)
*** Bug 3357 has been marked as a duplicate of this bug. ***
*** Bug 5622 has been marked as a duplicate of this bug. ***
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).
The page could be called "Special:Lockedlemmas"(?) or maybe better "[[Special: Lockedtitles]]".
Would Bug 3951: Add __NORANDOM__ magic word to force page_random = 0 be usefull if included in {{Gesperrtes Lemma}}) mentioned at bug 5622?
Regardless of the problem with blocked lemmas i like the idea of a __NORANDOM__ magic word :)
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.
Created attachment 2845 [details] Implementation details I made this extension now, that I suspect will have the ability to lock down titles for creation
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 MediaWiki.org needs to lose the .php suffix.
Created attachment 2846 [details] Updated patch Have tried to do what Rob Church said, here's the result :)
Avoid setting a UTF8 character set in the SQL, since it's not compatible with older versions of MySQL.
I think this would be best integrated into the core protection code, no? Although this is better than nothing, certainly.
(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.
(Removing patch keywords, since what you've got there is basically an extension, not a patch against the core code.)
On en.wikipedia there is currently a proposal to (ab)use cascading protection to mimic what's requested in this bug here. See http://en.wikipedia.org/wiki/Wikipedia:Village_pump_%28proposals%29#Salted_pages. 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.
While a dedicated feature obviously would be preferable, I disagree that this use of cascading protection constitutes abuse.
(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.
Stupid question: Why must for example http://en.wikipedia.org/w/index.php?title=User:Ligulem/XYZ&action=protect return an error message (the page is inexistent)? Couldn't the relevant checks in MediaWiki turned into acceptable use cases?
Because protection only works for pages that exist. Removing the error message would be rather silly until support for protecting nonexistent pages is added. :)
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.
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.
Fixed through introduction of cascading protection.
(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.
Implemented in r28385.
