Not planned Compile Each Event Listener Type Into Single PHP File

digitalpoint

Well-known member
I've been working more or less non-stop building all the vB customizations I've done over the years for XF.

Most are just small little things, but in the end even small things take a bunch of PHP files when doing it MVC style. For example giving forums a default sort order requires 9 PHP files, 4 of which are listeners... so at a minimum it's adding 4 unique PHP being called for every page view and depending on how many models/template hooks are triggered, each of those are being called numerous times.

By the time I'm done I'm probably going to have hundreds of Class Controller listeners alone... every page view is probably going to be including at least 500 unique PHP files, with a bunch of those being called multiple times.

Maybe not a bad idea down the road to just grab all the enabled listeners and consolidate them into a single PHP file per listener type?
 
Upvote 12
This suggestion has been closed. Votes are no longer accepted.
Could you describe as an example how to work with your hint system and your adPositioning? That would be great!
Not sure what you mean to be honest... if you specify a hint (being the first parameter of the event listener), it will run those... if you don't specify a hint (and leave it like it is normally), it will just run it globally like it does now.
 
I have replaced both functions and added the hint row. Your addon should then do no changes, right? But all my addons are deactivated. I guess there is some kind of bug.

I have not understand the "first parameter of the event listener" to specify the hint. As an example, how would you do that with your adPositioning product?
 
I have replaced both functions and added the hint row. Your addon should then do no changes, right? But all my addons are deactivated. I guess there is some kind of bug.

I have not understand the "first parameter of the event listener" to specify the hint. As an example, how would you do that with your adPositioning product?
I believe he's referring to the Listener, so:
PHP:
class MyClass_Listener
{
     public static function listen($hint, $class, &$extend){
         //code   
    }
}

I could be wrong.
 
Side note... with the default way XenForo calls event listeners, this is how many are being called for a single page view on various pages on my site (basically just because of how a ton of models and template hooks are being called for each page, so they exponentially compound):

Main forum page: 1,205
Forum view: 2,566
Member profile: 3,094
Thread view: 1,878
 
It sounds like a logical next iteration of the code, but does it actually provide an improvement in a real-life situation?
 
I just spent the last 2 days going through all my stuff and utilizing the event listener hints on everything as well as completely eliminate all use of the template_hook listener. They have all been moved to the new template modification system (and in some cases some template callbacks. Pages are noticeably faster, way less PHP files included to render a page, etc.

Time for bed.
 
Are template_hooks slower than using the template modification system?

Is it faster to use the system by replacing a template_hook with "template_hook<xen:include template="abc" />" than using template_hooks?

Or is it faster to include a <xen:callback> and receive a view?
 
Last edited:
Yes... Template hooks will be slower than changes made with the template modification system. Template hooks are evaluated in real time. Template modifications are just evaluated when the template is compiled.
 
Side note... with the default way XenForo calls event listeners, this is how many are being called for a single page view on various pages on my site (basically just because of how a ton of models and template hooks are being called for each page, so they exponentially compound):

Main forum page: 1,205
Forum view: 2,566
Member profile: 3,094
Thread view: 1,878
I went and ran the same tests now that everything is refactored...

Main forum page: 25
Forum view: 30
Member profile: 41
Thread view: 44

So on average, each page view is making over 1,500 less calls to functions to event listener definitions to see if something needs to be extended.
 
Top Bottom