The test suite set $wgTitleBlacklistSources with a fixture source of
directories. Unfortunately when running tests from MediaWiki core the
TitleBlacklist has already been set with empty value and thus setting
the global is a noop.
That later causes a test to fail because the blacklist is emtpy.
Add TitleBlacklistTest::destroySingleton() so a test can reset the
singleton when changing $wgTitleBlacklistSources.
Since that is solely for testing, throw an exception unless we had
MW_PHPUNIT_TEST defined.
Bug: T155980
Change-Id: I99c3185811ed7b2225953fa6960096985e97c4d2
It looks like the original implementation of this (r28307) was
incorrectly using wfEmptyMsg() so it was checking if the specified
message page had content equal to '<titleblacklist>' rather than
checking whether the message actually being loaded was empty.
Then r64178 changed wfEmptyMessage() such that it was checking if the
'titleblacklist' message was disabled in the user's language, which
caused the behavior here to be even more wrong. Then Ie78fa258 came
along to cement this in place and make this code even more
incomprehensible.
So let's go back to what it was probably originally trying to do: return
the 'localpage' message's content if it's not disabled, or empty string if
it is disabled.
This should also take care of T56193#2068536, which is being triggered
by the attempt to load the message in the user's language.
Bug: T56193
Change-Id: I8fe7f03d68e6854106cc903baf7c14ba4badb7c7
The `tboverride` permission is not widely granted, so checking for the user
right before checking whether the title is blacklisted optimizes for the
uncommon case.
Change-Id: Ie6ebdf8b9b87d70ebbf2929a5da325f964464e1d
There was never any use-case given for this, nor was there a bug report
about it, and it doesn't seem useful in any way, so remove it. Also, add
comments so that it's obvious when grepping that the messages aren't
unused now.
Change-Id: I80079fb4822fbc4f47df592119b1b1f8a367927c
Add lua method mw.ext.TitleBlacklist.test(action, title), which tests
whether a titleblacklist entry is active for a given title and action, and
if so, returns details of the entry.
Change-Id: I4360d1ad4e602d58dabd12b683d338a0e09a2950
Introduces a new "antispoof" parameter. If set, try to normalize
the title using the AntiSpoof extension.
Bug: 53901
Change-Id: I9b3c5f5f5d9eeda65562fd83e21c9c2ba97e5569
* Name all sources and track them inside the entries. This should be
fully backwards-compatible with previous configuration format,
since numbers may be a legitimate source names as well.
* Introduce $wgTitleBlacklistUsernameSources as a variable which allows
to specify which sources may be used for filtering usernames.
Change-Id: Ia2702370c85f317c763e345c8f92cb38e23e4196
Aug 8 23:22:25 srv35 httpd[5547]: PHP Fatal error: Using $this when not in object context in /home/wikipedia/common/php-1.5/extensions/TitleBlacklist/TitleBlacklist.list.php on line 98
Fatal error: Call to private method TitleBlacklist::parseBlacklist() from context 'TitleBlacklistHooks' in /Library/WebServer/Documents/trunk/extensions/TitleBlacklist/TitleBlacklist.hooks.php on line 90
UsernameBlacklist extension is unmaintained, rather brittle, and only
supports a single local blacklist, and also on most wikis both
blacklists will be closely intertwined if not identical, it seems
logical that TitleBlacklist take over both functions. :)
