https://bugzilla.wikimedia.org/show_bug.cgi?id=42064
--- Comment #16 from Daniel Kinzler <[email protected]> --- Hm... such an Interface would mean a hard dependency on AbuseFilter. And what information would it provide? AbuseFilter uses a wide variety of "variables" (I would call them "features"), plus a mechanism for only calculating these on demand. To provide full flexibility, the interface would have to be very generic, perhaps only defining the method getEditVars similar to the one in AbuseFilter.class.php. But that doesn't solve the question of when and how to trigger AbuseFilter when saving an update to a Wikibase Entity. We still need an alternative to EditFilterMerged for that. I started to work on this issue yesterday, and came up with the following idea: 1) modify the EditFilterMergedContent hook to be more generic, so it can be called from EditEntity as well as from EditPage. The most important change woudl be to pass an IContextSource as the first parameter instead of the EditPage. That already provides most information needed, including the WikiPage object. Modifying hooks is of course not to be taken lightly, but EditFilterMergedContent was only introduced in 1.21 as a Content-object aware alternative to the now deprecated EditFilterMerged. No extension is using it yet (AbuseFilter was due to be changed to use the new hook anyway). 2) make EditEntity call EditFilterMergedContent. 3) Make AbuseFilter use EditFilterMergedContent instead of EditFilterMerged. 4) Add hook points to AbuseFilter that allow other extensions to control how "variables" are extracted from the present Content object. 5) make Wikibase provide handlers for these hooks that implement the variable extraction suitable for Wikibase Entities. A quick-and-dirty way would be to implement a hook function for generating fake wikitext from an Entity. This architecture keeps the two extensions largely independent, though it requires Wikibase to have some knowledge about AbuseFilter. This kind of cross-extension knowledge seems to be unavoidable, we will probably also provide special hook handlers for MWSearch and perhaps some more extensions. It would be cleaner to have this "glue code" in a separate extension, but that would be annoying overhead. What do you think, Chris? Does that work for you, or would you prefer using a specialized interface? I suppose instead of implementing a handler for an AbuseFilter::getEditVars hook, EntityContent could implement a function called getAbuseFilterVars, and AbuseFilter could check for that instead of calling the hooks... nicer from an OO perspective, but not How Things Are Generally Done in MediaWiki. -- You are receiving this mail because: You are on the CC list for the bug. You are watching all bug changes. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
