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