There are a number of pages that it'd be nice if this was done for. Bad image list, sidebar (especially the sidebar ;), etc could all use special page interfaces.

I wonder if it'd be possible to have a generic special page for managing lists (This wouldn't apply to sidebar, but there's many mediawiki pages that aren't i18n pages are simple lists of things).

(In reply to comment #1)

There are a number of pages that it'd be nice if this was done for. Bad image
list, sidebar (especially the sidebar ;), etc could all use special page
interfaces.

I wonder if it'd be possible to have a generic special page for managing lists
(This wouldn't apply to sidebar, but there's many mediawiki pages that aren't
i18n pages are simple lists of things).

As pointed out to me on irc, I cannot read :). I do think making special pages to manage these lists hacked on to the system message i18n system would be cool, but that's a separate issue.

happy.melon.wiki wrote:

It's certainly doable; but they'd need to be able to store their data in some database table, and it's not immediately obvious which one, or what schema a new table should have.

GUI sidebar is bug 16943

We could leave the mediawiki pages where they are and add them to MediaWiki:MessagesOnlyViewableBySysops.

(In reply to comment #5)

We could leave the mediawiki pages where they are and add them to
MediaWiki:MessagesOnlyViewableBySysops.

Per-page restrictions are unreliable.

I don't think that hiding new things is a good idea. For your vandal problem, you could use AbuseFilter with a hidden filter.

thor.malmjursson wrote:

Platonides: please refer back to my OP here:

"I know we have the abuse filter, but at present, as far as I can tell, nobody
on our users actually knows how to configure it to add anything"

I've asked on our irc channels, asked among staff, nobody knows how to get the AbuseFilter to work. Is there any documentation on the Abusefilter listed anywhere so some of us can actually learn how to use it, since this suggesting is looking increasingly unlikely to get actioned?

Sorry, i missed it.
You do seem to have several users that made filters in the past (see Special:AbuseFilter).
The most knowledgeable person on AbuseFilter is Werdna (its author)

I'm no expert either but I think that the condition
(action == createaccount) & (user_name regex "foo+")
with "Prevent the user from performing the action in question" should do it (with a proper regex in place).

The documentation seems to be at
*http://www.mediawiki.org/wiki/Extension:AbuseFilter/RulesFormat
*http://www.mediawiki.org/wiki/Extension:AbuseFilter/Actions

shealen.clare wrote:

It seems that this is really the intended purpose of the AbuseFilter. Can we say that this problem is actually a need for proper AbuseFilter documentation, and submit a feature request on that component?

Also, this bug has not been touched in at least six months. With this in mind, I've been asked by the bugmeister to bump this bug's priority down for "High". Concerns can be addressed to mah@everybody.org.

Wouldn´t the Phalanx extension solve this bug?

This isn't actually being worked on by RobLa; de-assigning.

As a note on the enhancement, it'd be nice, but of course all the functionality of titleblacklist is present in AbuseFilter - we could just get users to move the rules over and switch off the extension?

(In reply to comment #12)

This isn't actually being worked on by RobLa; de-assigning.

As a note on the enhancement, it'd be nice, but of course all the
functionality
of titleblacklist is present in AbuseFilter - we could just get users to move
the rules over and switch off the extension?

I don't neccesarily think a system that does everything is a good thing. Small systems that solve specific problems are good. As has already been noted previously, abusefilter is very complex compared to titleblacklist

As for the actual bug. Its honestly not that hard to get around blacklists via trial and error when you can try as many times as you want, even if you dont know what is on the list (essays about hard security vs soft security from meatball come to mind). A form based system would be more a win in usability than security imho. Replacing titleblacklist with abusefilter would be a massive loss for usability.

(In reply to comment #13)

(In reply to comment #12)

This isn't actually being worked on by RobLa; de-assigning.

As a note on the enhancement, it'd be nice, but of course all the
functionality
of titleblacklist is present in AbuseFilter - we could just get users to move
the rules over and switch off the extension?

I don't neccesarily think a system that does everything is a good thing.
Small
systems that solve specific problems are good. As has already been noted
previously, abusefilter is very complex compared to titleblacklist

As for the actual bug. Its honestly not that hard to get around blacklists
via
trial and error when you can try as many times as you want, even if you dont
know what is on the list (essays about hard security vs soft security from
meatball come to mind). A form based system would be more a win in usability
than security imho. Replacing titleblacklist with abusefilter would be a
massive loss for usability.

...and that´s why mw:Extension:Phalanx would be a much better option than the AbuseFilter for this bug. Phalanx already covers TitleBlacklist and it is much easier to use than AbuseFilter. The Admin tools development team are thinking of enabling Phlanx to WMF wikis - see mw:Admin tools development .