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 _______________________________________________ Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l
