This resulted in doubling the appserver-memcached traffic across the
Wikimedia cluster.
This reverts commit 32b546a223.
Change-Id: I03e96a1bb223360e62d47f98a505cc5b26e5aadf
Add API action spamblacklist, accepting parameter url, that returns the
parts of the URLs that match the spam blacklist, if any.
Bug: 54441
Change-Id: Ia6aea8b463fc63f951224520b8cc5abf185c5c74
This changes SpamBlacklist to make use of the new, ContentHandler
aware hooks.
This change also includes some refactoring and cleanup which made
the migration to the new hooks easier.
Change-Id: I21e9cc8479f2b95fb53c502f6e279c8a1ea378a5
The default blacklist was no longer being used, because the line
$wgSpamBlacklistFiles =& $wgBlacklistSettings['spam']['files']
initialized $wgBlacklistSettings['spam']['files'] to null,
and BaseBlacklist::__construct then overrode $this->files
with null.
Change-Id: I22448bfb87eef6dd86b61362f3eb6bb2198a10b6
Adds a logBlacklistHit function function, which is callend whenver a new url
matches the blacklist. A new log type of "spamblacklist" is created, and is only
viewable by people with the "spamblacklistlog" userright. This is given to sysops
by default.
By default this is disabled, and is controlled by $wgLogSpamBlacklistHits.
Bug: 1542
Change-Id: I7b1ee2b3bb02b693d695bf66d157e2c33526c919
I am on a slow connection today and it took me about an hour
to understand why does saving a page take about 25 seconds.
Note: this commit requires changes to Wikimedia configuration files.
Change-Id: I2d99fe36c3371d2a2a22dbb68e063287d9f4f82d
There was a mix of uses of the reference and non-uses of the reference. :)
Reverts r53714 and fixes it from the other end by cleaning up the uses to not expect references.
An API edit attempt with Spam Blacklist firing will now output something instead of crashing:
<?xml version="1.0"?><api><edit spamblacklist="http://blacklistme.example.com"
result="Failure" /></api>
* Use the new EditFilterMerged hook if available, for faster link finding
* Random bits of code were leaking out of the body file into the loader, poked them back in.
* Handle bad regexes more gracefully:
- The batched regexes are tested for validity, and if one is bad, the lines from that source are broken out line-by-line. This is slower, but the other lines in that source will still be applied correctly.
- Suppress warnings and be more verbose in the debug log.
- Check for bad regexes when a local blacklist page is edited, and prompt the user to fix the bad lines.
* Caching issues:
- Cache the full regexes per-DB instead of per-site; this should be friendlier to shared environments where not every wiki has the same configuration.
- Hopefully improve the recaching of local pages, which looked like it would preemptively apply the being-edited text to the cache during the filter callback, even though something else might stop the page from being saved. Now just clearing the cache after save is complete, letting it re-load later.
* Split out some of the regex batch functions for clarity.
There are probably still issues with caching of HTTP bits, and in general the local DB loading looks verrrry fragile.
Test this a bit more before syncing. :)
