User/Developer Defined Hooks

SneakyDave

Well-known member
Assuming a familiar hook/plug-in system is included with xenforo, would it be possible or even feasible to include a feature allowing a developer to create their own hook locations? I assume this would have to be some kind of pre-parser of the code to insert the hook, and may increase a security risk, but if done correctly, could open up a number of new xenforo apps, without xenforo developers trying to determine good candidates for hook locations
 
Upvote 0
Doesn't sound like a safe thing to do. OTOH, if they built into their objects default hook locations, that may help everyone. Crap load of hooks though lol!
 
XenForo won't use traditional hooks like vBulletin:
eval() is still used for templates currently. The template syntax is very rich, so it compiles down to native PHP code as you might expect and these are loaded from the DB on demand. There is code in our template class to read them from the file system, though this functionality hasn't been completed yet; at the least, it's been considered since the beginning as this would allow byte code caching (APC).

Plugins (well, "code event listeners") don't use eval. You specify a class+method and that is (auto)loaded and your code is run. The listener is given a specific set of arguments, similar to MediaWiki. This actually makes it documentable, and allows more backwards compatibility or at least documentation of potential issues.

Eval() not withstanding, I'm not sure how HipHop would handle the code. We haven't run it through the static analyzer yet, though it's on the cards. I'm not sure how it would handle including template files, and you would certainly have to recompile if you edited a template.

Not sure how it will be exactly implemented. If the listener is flexible, you could probably create a "hook" almost anywhere you need one. :)
 
vBulletin allowed custom hook locations by specifying the hook name in the XML file and creating the location. It was nice.

You have to remember that hooks that are hard-coded will be removed on upgrade.
 
vBulletin allowed custom hook locations by specifying the hook name in the XML file and creating the location. It was nice.

You have to remember that hooks that are hard-coded will be removed on upgrade.
It was horrid! Too many people asking after a vB upgrade: "Your %#$@ mod stopped working, FIX IT NAOW!" /troutslap
 
Thanks for the info, on a side note, I couldn't find if xenforo would be built with a common MVC in mind, or a custom MVC, or no MVC, just out of curiosity. Are there any topology diagrams about how things work together?
 
Thanks for the info, on a side note, I couldn't find if xenforo would be built with a common MVC in mind, or a custom MVC, or no MVC, just out of curiosity. Are there any topology diagrams about how things work together?

They said it's built on MVC principles - not sure what that exactly means. :)
 
When asked if I would be porting any of my mods from vB to XF, I had this to say:
"It ... depends if the plugin system that they implement offers at least the same amount of customization that vB3's did. While eval() has its extra overhead, it does allow you to modify anything in the current scope, which listener classes+methods don't really allow, unless they were written to emulate eval, in which case, I don't know if any performance is really saved... The best alternative I think is a file-based plugin system, where instead of eval() it just uses include() based on a registry of files, similar to how scheduled tasks are added in vB." (view original post)

I think that the OP was suggesting a way to add your own hook locations should you write a custom script for XF and would like other modders to be able to mod your custom script using the XF framework.
 
Customisability and the ability to mod will be essential for mass adoption. Unless there is some new method of extensibility I haven't seen, evaling or including will have to be the order of the day. Extending library classes is elegant but it also has overhead and many limitations that a simple eval or include will dance around.

Personally I prefer the include method over eval and am not sure why it hasn't been implemented yet. Looking at a lot of vB mods, there were often times reams of pages worth of php code sitting in memory every page load just in case it was needed. That was fugly and wasteful. 99.9% of the time, the only thing I ever had in a hook was an include and function call (possibly wrapped in a test). Maybe the best approach would be a hybrid that eval'ed but limited the code to 140 characters :)

Regardless I am looking forward to what the team here whips out ;)
 
Top Bottom