Last modified: 2013-03-05 19:46:12 UTC
When an external link http:// is used within a [[wikilink]] AND has a leading space such as [[ http://www.anu.edu.au]] the link is created as an internal redlink to itself. Such a "link" also avoids the blacklist. It would seem worthwhile to 'chomp' any leading spaces inside a [[wikilink]], especially where the character after the space is a url. Example: https://meta.wikimedia.org/w/index.php?title=User:Billinghurst/sandbox&oldid=3585709
Lowering priority on high priority bugs that have a low severity
This is a WONTFIX on two counts: 1. SpamBlacklist (which is a horrible hack) is for blocking external links. "[[ http://foo.com/]]" isn't an external link, even if it contains some text that looks like one to a human, so doesn't get caught by it. A better way in general of dealing with spammy links is a global AbuseFilter, as that isn't focussed just on one . To use it in a filter directly, the code is written, and will be enabled soon; to have a proper spam-fighting capability in AbuseFilter is a route we haven't yet explored, but seems more sensible than fixing archaïc code. I've created a bug for that as bug 45747. 2. We're trying really, /really/ hard not to add more hacks onto the PHP parser at this point, as we're looking forwards to the point when Parsoid replaces it; as it is, the workload to create "bug-for-bug comptability" with the PHP parser is extreme, and changes to how it works is something to avoid. Additionally, changes to corpus interpretation that may be unexpected are generally not great - it's astonishing how many times our users delibaretly use the edge-cases of 'unexpected' behaviours to do something odd but intentional. Sorry!
