On 12/05/2012 07:55 PM, Chris Steipp wrote:
If Wikibase wants to define another hook, and can present the data in a generic way (like Daniel did for content handler) we can probably add it into AbuseFilter.
It should be presented in a suitable way (not obscure Wikibase internal structures), that still includes the necessary information.
But if the processing is specific to Wikibase (you pass an Entity into the hook, for example), then AbuseFilter shouldn't be hooking into something like that, since it would basically make Wikibase a dependency, and I do think that more independent wikis are likely to have AbuseFilter installed without Wikibase than with it.
AbuseFilter would not depend on Wikibase if AbuseFilter only hooks into it.
It's fine for you to register a hook that is never called:
$wgHooks[ 'WikibaseEditFilterMerged' ][] = 'AbuseFilter::onWikibaseEditFilterMerged';
will not cause an error if Wikibase is not installed. onWikibaseEditFilterMerged would then transform the data and call internal AbuseFilter functions/methods.
I don't think it necessarily needs one. A spam filter with a different approach (which may not have a rule UI at all) can register its own hooks, just as AbuseFilter does.
I can definitely appreciate that, but that is also why we currently have so many extensions for spam / bot handling, using the existing hooks. I would hate to see yet another spam extension that does really great spam detection, but is has a dependency on Wikibase.
I think inevitably different people are going to address the spam challenge differently. By using hooks, though, that great extension does not need a hard dependency on Wikibase.
Matt Flaschen