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?

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.

Oh, wow - 10 parameters for the hook function? Somehow that seems like overkill, though I don't know what exactly could be removed from that list. Would the call to wfRunHooks() be placed before or after the line that sets the actual link ($s)? If it comes afterwards, passing in the variables of $style and $inside might not be necessary, since those are just helper variables that are used to create the link. Maybe it's also better to not have makeBrokenLinkObj() override the values of $text and $trail, and instead use new variables for those, so that the original values could be passed in without problems (and the new variables could similarly be ignored). -Yaron On Wed, Mar 5, 2008 at 12:43 PM, Simetrical <Simetrical+wikilist(a)gmail.com> wrote: _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l

I would like to say thank you for adding going through this as well :) regarding jimbojw's words: I would agree it could be nice to have case-diff links be known link objects, however, though I can't think of an example atm, I'm sure there are articles with the same name but different cases - and then it becomes a problem of trying to understand which is the one the user meant. Places like search, where TitleKey makes a lot of sense, let the user make a conscious choice by showing him all of the options. --Wiredtape Jim Wilson wrote: > Thanks Yaron for taking on the task of adding this hook :) > > One use case could be for integration with something like Brion's > TitleKey extension, so if the title already exists, but with a > different capitalization, a known link obj could be generated rather > than a broken link obj. > > Say for example you're using TitleKey with an additional > ArticleFromTitle hook to automatically resolve case differences > (perhaps by 301 redirecting), and the article "WiMAX" already exists. > When someone links to [[wimax]] - it would be nice to be able to show > that as a known link obj. > > -- Jim R. Wilson (jimbojw) > > On Wed, Mar 5, 2008 at 11:59 AM, Yaron Koren <yaron57(a)gmail.com> wrote: >> Oh, wow - 10 parameters for the hook function? Somehow that seems like >> overkill, though I don't know what exactly could be removed from that list. >> Would the call to wfRunHooks() be placed before or after the line that sets >> the actual link ($s)? If it comes afterwards, passing in the variables of >> $style and $inside might not be necessary, since those are just helper >> variables that are used to create the link. Maybe it's also better to not >> have makeBrokenLinkObj() override the values of $text and $trail, and >> instead use new variables for those, so that the original values could be >> passed in without problems (and the new variables could similarly be >> ignored). >> >> -Yaron >> >> >> On Wed, Mar 5, 2008 at 12:43 PM, Simetrical <Simetrical+wikilist(a)gmail.com> >> wrote: >> >> >> >> > On Wed, Mar 5, 2008 at 12:33 PM, Yaron Koren <yaron57(a)gmail.com> wrote: >> > > 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. >> > >> > Putting it at the bottom with more parameters seems like a better >> > idea, on second thought. I'd still permit hooks to return false and >> > alter some $ret variable to totally change things if they wanted, but >> > exposing the parameters $u, $style, $prefix, the modified $text, >> > $inside, and $trail (as well as $nt, $query, and the unmodified $text, >> > for reference) could allow some extensions to coexist peacefully. If >> > there's a conflict there's a conflict, of course, but we may as well >> > try to avoid that a bit more. >> > >> > _______________________________________________ >> > Wikitech-l mailing list >> > Wikitech-l(a)lists.wikimedia.org >> > https://lists.wikimedia.org/mailman/listinfo/wikitech-l >> > >> _______________________________________________ >> Wikitech-l mailing list >> Wikitech-l(a)lists.wikimedia.org >> https://lists.wikimedia.org/mailman/listinfo/wikitech-l >>

Oh, wow - 10 parameters for the hook function? Somehow that seems like overkill, though I don't know what exactly could be removed from that list.

Would the call to wfRunHooks() be placed before or after the line that sets the actual link ($s)? If it comes afterwards, passing in the variables of $style and $inside might not be necessary, since those are just helper variables that are used to create the link.

Maybe it's also better to not have makeBrokenLinkObj() override the values of $text and $trail, and instead use new variables for those, so that the original values could be passed in without problems (and the new variables could similarly be ignored).

One use case could be for integration with something like Brion's TitleKey extension, so if the title already exists, but with a different capitalization, a known link obj could be generated rather than a broken link obj.

That would be much better done as a hook in makeLinkObj(). You're running extra queries for no good reason if you wait till it's already been decided broken, and you might break other things too.

Well, maybe we can break two records at once. :) Okay, I guess I'll add the hook in later today, following your specifications. -Yaron _______________________________________________ Wikitech-l mailing list Wikitech-l(a)lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikitech-l