Hi,
Okay, that makes sense - there's probably no reason to allow more than one hook to override the output. The one downside of this approach that I can see is that functions that don't override the output might not get called at all, if they're later in the array than a function that does override it. I don't think that's a big deal, since I can't imagine some large amount of custom code called for every broken link, or two extensions "collaborating" on creating a new link. Unless anyone objects, I'll go with your suggestion.
-Yaron
On Wed, Mar 5, 2008 at 12:02 PM, Simetrical Simetrical+wikilist@gmail.com wrote:
On Wed, Mar 5, 2008 at 11:49 AM, Yaron Koren yaron57@gmail.com wrote:
The idea of having it at the top of the function, and making it more comprehensive, makes sense; but I don't understand the specific code
you
suggested. My understanding is that wfRunHooks() normally returns true;
in
that case, if the call is placed at the top of the function, whatever
value
the hooks set the broken link to will get overridden by
makeBrokenLinkObj()
itself. Or is the idea that every function that uses this hook should
return
false, thus ensuring that no more than one function is called for it?
The idea is that functions could do two things:
Override the output entirely, by setting $ret and returning false.
Modify the function's parameters, and return true.
I'm not sure how much more flexibility is reasonably possible. It doesn't seem like it would make much sense for multiple extensions to modify the appearance of broken links in really arbitrary ways. What would you suggest? The hook could be near the bottom instead, right before the definition of $s, with lots more parameters. By that point, some of the original parameters (like $text) have been overridden, but that could be changed.
Wikitech-l mailing list Wikitech-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l