Last modified: 2012-12-21 01:16:13 UTC
MediaWiki does not come with good anti-spam protection included in the source tarball. It needs to. Why? Because, out of the top 10 PageRanked MediaWikis[1], 7 of them require logging in to edit, and that's bad: "People often naively suggest lock-down as best solution to wiki spam. It does reduce spam, but it is a poor solution (and a Lazy Solution), because you are introducing something which massively inconveniences real users. Having to choose a username and password is a big turn off for many people. The wiki way is to be freely and openly editable. This 'soft security' approach is one of the key strengths of the wiki concept. Are you going to let the spammers spoil that?" --[2] To get more wikis to be freely editable, MediaWiki would need to have spam protection built in. [1] http://www.wikihow.com/ , http://microformats.org/wiki , http://www.benkler.org/wealth_of_networks/ , http://wiki.43folders.com , http://wikitravel.org/wiki/en , http://wiki.laptop.org/ , http://wiki.mozilla.org , http://www.knoppix.net/wikinew , http://labs.adobe.com/wiki , http://wiki.linuxquestions.org/ [2] http://meta.wikimedia.org/wiki/Anti-spam_Features
It might be time to start packaging a few extensions as part of core MediaWiki, yeah. In particular, since a lot of people expect the same functionality as Wikipedia, maybe we should include all the extensions Wikipedia uses, at least those that consist of a few PHP files and at most one or two *small* images: those will compress to negligible size anyway, so why not? We can include some lines at the bottom of LocalSettings.php commented out by default, with comments indicating how to enable them. Extensions are nice because they modularize functionality (which can give slight speedups to those who want it, remove unnecessary expansions of wikisyntax, etc.), but there's no reason not to include some of the most useful/popular in the default tarball for easier installation. Potentially we could even move some stuff from core, like the less useful core parser functions or <gallery>, to "extensions" that are enabled by default.
(In reply to comment #1) > It might be time to start packaging a few extensions as part of core MediaWiki, > yeah. Do all the useful anti-spam features come packaged in extension form, or are they enabled in other ways? [snip] > We can include some > lines at the bottom of LocalSettings.php commented out by default, with comments > indicating how to enable them. I propose the anti-spam functionality be on by default. :-)
$wgSpamRegex is core; the Spam Blacklist is an extension.
Note the existence of http://www.mediawiki.org/wiki/Manual:Combating_spam, which offers a tiered guide to dealing with the problem of spam using escalating measures of protection. It would be a good idea to bundle the Spam Blacklist with distribution packages.
(In reply to comment #4) > Note the existence of http://www.mediawiki.org/wiki/Manual:Combating_spam, > which offers a tiered guide to dealing with the problem of spam using > escalating measures of protection. Cool. > It would be a good idea to bundle the Spam Blacklist with distribution > packages. What tool do you use to make the MediaWiki .tar.gz packages you release on www.mediawiki.org? Is the tool in SVN? Could I send a patch to the tool to include the extension preinstalled in your .tar.gz packages?
svn and tar. That's not relevant -- what's needed is improvements to the installer script to be able to enable any bundled extensions during installation.
(In reply to comment #6) ... > That's not relevant -- what's needed is improvements to the installer script to > be able to enable any bundled extensions during installation. Oh. Then I'm taking the liberty of renaming this bug from "Bundle anti-spam extensions in distribution packages" to "Please let install.php auto-enable extensions bundled in a MediaWiki tarball". Or was that a mistake and I should have filed a new bug instead? If so, feel free to rename the bug back.
install.php being able to enable bundled extensions is necessary but not sufficient for this bug to be properly fixed.
(In reply to comment #8) > install.php being able to enable bundled extensions is necessary but not > sufficient for this bug to be properly fixed. OK. So I now filed Bug 10596 (Please let installer auto-enable extensions bundled in a MediaWiki tarball) and made this bug depend on it.
Please bundle SpamBlacklist. Here is an extension config.php you may use. Public domain. No warranty. <?php $extension_config = array(); $extension_config[] = array( 'name' => 'SpamBlacklist', 'label' => 'SpamBlacklist', 'description' => 'Click here to install the <a href="http://www.mediawiki.org/wiki/Extension:SpamBlacklist">SpamBlacklist</a> extension. It downloads and installs a blacklist of websites that users of your wiki will be forbidden to link to.', 'file' => 'SpamBlacklist/SpamBlacklist.php', 'config' => '', 'download' => 'http://www.mediawiki.org/wiki/Extension:SpamBlacklist' ); Note that you will be unable bundle it till Bug 10596 is fixed.
Moving this to an extension request.
Moving back to MW -> general/unknown per requests elsewhere. It's not really an extension issue ;-)
This should use the blacklist on Meta. Better yet, SpamBlacklist would be rewritten before we start bundling up experimental extensions - see bug 4459.
ConfirmEdit is bundled.. Anything else can be bundled with reasonable consensus
