XF 2.0 Looking for Hook Alternative

[[xFv]]

Hello!
In XF1 we used to be able to use a listener to hook into the forum like example below.

<?php
class some_class
{
    public static function templateHook($hookName, &$contents, array $hookParams, XenForo_Template_Abstract $template)
    {
        switch ($hookName) {
            case 'Some_hook':
               $get_template = $template->create('Some_template', $template->getParams());
                   $contents = $get_template . $contents;
                   break;
        }
    }
}

Since hooks are gone in XF2, what would I use exactly or what would be the XF2 equivalent to this?

 

[Chris D]

They haven't been recommended to use for about 5 years. They were deprecated and have been removed in XF2.

You should be using "Template modifications". See the "Appearance" section in the Admin CP.

 

[Yugensoft]

Can I clarify why this design decision was made?

The template hooks presented a clear set of insertion points and groupings. In addition to that there were supplementary <!-- slot --> markers that could be used to grip into specific areas of the template with supplementary template modifications.

I don't see how going back to "choosing some arbitrary chunk of code to regex" is a superior solution to the clearly labeled template hooks and slot points. Perhaps there is something I'm missing.

Will this also not increase the chances of inter-addon clashes? As everyone is gripping on arbitrary code points to do modifications, instead of passive hooking labels, it seems this would increase the chance of someone modifying something that another addon is relying on existing.

 

[Jeremy P]

There's still quite a few <!-- slot --> markers in common places for use with template modifications. Given that, template modifications can pretty much do everything template hooks could do and lots that they couldn't. Template modifications are essentially a super-set of what hooks offer, so there's not really any reason to keep hooks around. I think performance is better with template modifications too as they are pre-compiled into the templates instead of being applied at run-time.

 

[RobParker]

There's still quite a few <!-- slot --> markers in common places for use with template modifications. Given that, template modifications can pretty much do everything template hooks could do and lots that they couldn't. Template modifications are essentially a super-set of what hooks offer, so there's not really any reason to keep hooks around. I think performance is better with template modifications too as they are pre-compiled into the templates instead of being applied at run-time.

It's @Yugensoft's last paragraph that's always confused me.

One addon could be looking for two lines of code but another addon could insert it's own code between them and then suddenly it all breaks.

 

[Jeremy P]

It's @Yugensoft's last paragraph that's always confused me.

One addon could be looking for two lines of code but another addon could insert it's own code between them and then suddenly it all breaks.

If the add-on is modifying the template instead of just adding things to it, sure. It's still possible to use template modifications in the exact same way as hooks (by adding things around the available slots) and avoid all of that though.

Prior to template modifications, you would need to have people edit the templates manually if you needed to do anything more complex than that anyways. Now there's a chance those changes will be applied automatically. And if there is a conflict, they can still be applied manually. So there's no true disadvantage here as far as I can see.

 

[DragonByte Tech]

Can I clarify why this design decision was made?

I am not affiliated with XenForo in any way, shape or form but as a developer who has made extensive use of both template hooks in XF1, and encountered conflict issues with template mods in XF2, I feel like I can offer some guesswork about this.

The template hooks presented a clear set of insertion points and groupings. In addition to that there were supplementary <!-- slot --> markers that could be used to grip into specific areas of the template with supplementary template modifications.

I don't see how going back to "choosing some arbitrary chunk of code to regex" is a superior solution to the clearly labeled template hooks and slot points. Perhaps there is something I'm missing.

The template hook system had a few core issues that are not present in template modifications:

1. Template hooks did not have access to all of that template's variables
   By design, template hooks only had access to the variables that were passed as hook parameters. If you wanted access to another variable defined in the template, well that's tough luck.
   
   
2. Performance
   If you wanted to render another template to insert into a template hook, you had to render the template via PHP on-the-fly, which is vastly sub-optimal compared to evaluating a template as a whole with <xf:include /> statements (or in-line template HTML).
   Furthermore, template hooks are compiled into the template during installation / activation, so even if you install literally every single addon in existence, your templates will take (near as makes no difference) no longer to render than they would if you had no addons installed. The difference in performance of pre-compiled vs. real-time compilation cannot be overstated, and scales exponentially the more addons the site installs.
   
   
3. Less chance of addon clashes
   If you used a template hook, all it took was $contents = 'foo'; instead of $contents .= 'foo'; in order to wipe out every other template hook that ran before you.
   On the other hand, template modifications make it harder to screw that up because you are doing a search & replace on stock XF HTML, so if you forget to add $0 to your replacement, you will immediately notice when you go to the page to preview your changes.
   Circling back to the .= vs = point, if you messed that up you would have no way of knowing you did this unless you were developing multiple modifications on your installation that both used this template hook, and you could tell one wiped out the other.
   That in itself is not a guarantee, because your incorrect template hook could run first on your site, but may not run first on other people's sites, so there's only a 50% chance you would notice the problem on your own local development environment.
   
   
4. Ability to see conflicts in the UI
   When working with template mods, you can instantly see whether they have applied to any given skin. There is no such analysis tool available for detecting where and why a template hook did not apply as you would expect.
   Once you can see which skins a modification was not applied to, you as a developer can analyse from there and figure out a solution. This is in stark contrast to a template hook, where you have no choice but to disable every single other template hook event listener from every single other modification and re-enable them one-by-one to find the culprit.

Will this also not increase the chances of inter-addon clashes? As everyone is gripping on arbitrary code points to do modifications, instead of passive hooking labels, it seems this would increase the chance of someone modifying something that another addon is relying on existing.

Yes and no. To be honest, the biggest offender is styles, not other add-ons. Styles that have extensive HTML changes as opposed to relying on CSS changes will have a much bigger chance of causing a conflict.

It is also true that addons do have the opportunity to cause problems, e.g. <div id="someId" being replaced by <div class="someClass" id="someId" by a developer, instead of <div id="someId" class="someClass" as it should be.

However, as that example illustrates, changes wherein addons may clash are changes that would not be covered by template hooks. None of the forum software I have ever worked with has had a template hook available to modify the definition of any given DOM element (be it via altering or editing attributes such as class or style, etc).

Therefore, if we compare template hooks and template modifications on a 1:1 basis - in other words, we choose to only consider template modifications that add child elements to the DOM rather than modifying the definition of a DOM element - I think you will find that the chance of addon clashes is severely diminished.

If we consider the argument that styles modifying the HTML makes even those template modifications more difficult, then we also have to consider the argument that certain styles could very well have inadvertently (or by ignorance) removed the template hook, rendering the template hook system completely useless, as opposed to only needing tweaks to the search definitions by the developers.

One addon could be looking for two lines of code but another addon could insert it's own code between them and then suddenly it all breaks.

That would simply be a case of poor programming by the first addon (that looks for two lines of code). I did this, with DBTech's various navbar-related template hooks, and I was forced to re-think my search parameters.

For those unfamiliar; our mods allow you to move the navbar tab to the right side (where account/inbox/alerts are), but it required some very specific HTML searches that broke on 3rd party styles. I had to switch to regular expressions, and make sure to get the quantifiers correct so that I didn't select more or less than what I needed, without relying on specific spacing in the HTML.

-------
In short, while the template modification system may pose more of a challenge to "get right", when you do "get it right" it is much more durable than template hooks, as well as having much better performance. It is also easier for developers to see where their modifications failed to apply, and devise a solution (due to in-line template display).

As I said at the start, I am not affiliated with XenForo in any way so this post is entirely my own subjective opinion and should not be taken as either indisputable fact nor the actual reason(s) why template hooks were abandoned.


Fillip

 

[Yugensoft]

OK, but it just seems it would be better to at least have <!-- [marker] --> laid out all through the templates to offer the same unified form of "code position indication" that template hooks did.

For instance, what if XF devs change a line during an update, that everyone happens to be using in their mod regex? It would cascade. Seems safer for them to be presenting <!-- [marker] --> everywhere which people would then grip on (and wouldn't ever need to change), reducing that risk.

 

[DragonByte Tech]

There are multiple such markers laid out where it makes sense to do so.


Fillip

 

[Xon]

It would definitely be nice for more distinct markers to be added to act as anchor points for regex template modifications. Especially at the ends of blocks.

 

[DragonByte Tech]

It would definitely be nice for more distinct markers to be added to act as anchor points for regex template modifications. Especially at the ends of blocks.

Absolutely no arguments here, especially when it comes to the right-side navigation area as I mentioned in my wall of text above. It would solve quite a few problems (long term, short-term it would cause problems as styles would have to be updated).

Perhaps we should start a compilation thread of marker locations along with use case


Fillip

 

[Chris D]

Would be worth adding to the suggestions forum.