API Extensions (The New Plugin/Hook System) Question
How can we intercept the methods we're extending, instead of having our extension methods invoke after the parent methods?
I.e.
class Myplugin_Api_User extends vB_Api_Extensions {
function save(...) {
// This executes after vB_Api_User::save does, meaning we can't change the output of the parent function directly...
echo 'Foo';
}
}
Also how do I extend classes outside the vB Extensions Api folder, like controllers?
Both are not possible for the moment.
Both are not possible for the moment.
... then how are we supposed to make mods without butchering the core software and making it difficult to install a mod?
Well, for the moment, you need to find a way (workaround) to do what you want.
Maybe you can extend another method that is called before save() finishes.
Maybe, you can create another controller to do what you want.
If you explain what you want to do, we will able to be more help.
Limitations to modifying vB5
You cannot run any extension method before its main API counterpart.
You cannot stop or change core API calls (for example those that make database updates).
You cannot alter or hook into existing database queries.
You cannot extend library functions.
You cannot extend or hook into any frontend functions.
You cannot access the actual API variables ($this->xxx)
You can't extend any API call that was called by instanceInternal()
Cannot hook into [most] ACP functionality.
If you have any others, please post them
You cannot run any extension method before its main API counterpart.
You cannot stop or change core API calls (for example those that make database updates).
You cannot alter or hook into existing database queries.
You cannot extend library functions.
You cannot extend or hook into any frontend functions.
You cannot access the actual API variables ($this->xxx)
You can't extend any API call that was called by instanceInternal()
Cannot hook into [most] ACP functionality.
Jesus Christ! Why even have a modification system, then?
Thanks for this list, though. We just aren't developing any more vB5 mods until these things are taken care of.
With two completely new systems (to replace plugins and template hooks [v1]), its obvious that we are going to find limitations to what can be done.
You can vote in the issues created in Tracker to get these "bugs" fixed faster.
Hi,
i am pretty new to vBulletin as we got a customer who insists on using vB 5 Connect....
Having a quick look at the vB Code (horrible!), i came to the same conclusion: There is no good way of modifing specific behaviors in vB without making changes to the core files thus losing the possibility to upgrade.
Sadly vB missed to implement some kind of event/hook system (sorry but these Template hooks just don't give enough flexibility for big changes).
I went to make use of the existing autoloader and modified both - index.php and api.php to always look (following name convention) if there is a custom implementation of the loaded Class.
Now I can easily override every Frontend Controller and API Class to integrate my own logic.
Its not the best way, but as far as i can see its the only way to go right now.
Anyone here tried something like this before?
Can you share/explain this in detail?
You realise that post is a year old ?
Yes, but even this would help more than the non-existing vb5 documentation...
and still it's not possible to modify core methods and classes?
a child class can not be helpful here while i need to modify parent methods withough changing core files directly!
No changes have been made at all as far as extentiosn etc are concerned.
Other things seem to take priority, so I doubt anything will change anytime soon.