gangleri wrote:

see also
bug 3627: Special:Contributions lists contributions twice (if new page was created)

gangleri wrote:

please ignore comment #1

see also
bug 3627: Special:Contributions lists contributions twice (if new page was

created)

mediawikibugs wrote:

*** Bug 3357 has been marked as a duplicate of this bug. ***

Wiki.Melancholie wrote:

*** Bug 5622 has been marked as a duplicate of this bug. ***

Wiki.Melancholie wrote:

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).

Wiki.Melancholie wrote:

The page could be called "Special:Lockedlemmas"(?) or maybe better "[[Special:
Lockedtitles]]".

gangleri wrote:

Would
Bug 3951: Add NORANDOM magic word to force page_random = 0
be usefull if included in {{Gesperrtes Lemma}}) mentioned at bug 5622?

mediazilla wrote:

Regardless of the problem with blocked lemmas i like the idea of a NORANDOM
magic word :)

seahen123 wrote:

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.

Implementation details

I made this extension now, that I suspect will have the ability to lock down
titles for creation

attachment LockDown.tar.bz2 ignored as obsolete

robchur wrote:

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.

Updated patch

Have tried to do what Rob Church said, here's the result :)

Attached:

robchur wrote:

Avoid setting a UTF8 character set in the SQL, since it's not compatible with
older versions of MySQL.

ayg wrote:

I think this would be best integrated into the core protection code, no?
Although this is better than nothing, certainly.

robchur wrote:

(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.

robchur wrote:

(Removing patch keywords, since what you've got there is basically an extension,
not a patch against the core code.)

ligulem wrote:

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.

ligulem wrote:

(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.

ligulem wrote:

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. :)

ligulem wrote:

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.

robchur wrote:

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.

cannon.danielc wrote:

Fixed through introduction of cascading protection.

robchur wrote:

(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.