Quote:
Originally Posted by squidsk
As Dave pointed out this also does nothing about products that implement their own custom hooks. Further where are these "product" directories located and how will vb know to look there for any particular hook, or are you suggesting that it should look in the product directory for every product for every hook to see if there's a file that should run on that hook? If not how are suggesting vb knows that a product wants to use a particular hook? If so that's very inefficient.
|
No problem, those in-product hooks can be handled/rewritten by the converter non-destructively just like the core hooks. The plugin table provides a database reference to the plugins, there is no apache-style recursive folder scanning.
Quote:
Originally Posted by Paul M
The hook code you are referring to does not exist in vB5, only vB4 & vB3.
No such major change will ever be made to them, since they are no longer in development.
(Even if they were, its unlikely this would ever have happened, since its a major redesign of the way hooks work).
As an aside, requesting changes to any vB core requires a Jira, its never going to happen (even for vB5) from a thread on this forum (or indeed on vbulletin.com forum).
|
Yes, that is why I said Legacy plugins;
There have been updates made to vB 3.x recently so I was under the impression some of the staff here was informally keeping the product up to date, so wanted to go straight to the source.
I think due to the nature of the redesign it's actually not that big of a deal to implement on a technical level, almost nothing can break, but the benefits for people, especially those who got hacked, can be big.
Also, I can't log into JIRA and I'm showing as unlicensed here so I couldn't post it anywhere else.