Won't fix Template modifications still applied during add-on uninstall

DragonByte Tech

Well-known member
Affected version
2.0.2
I have the following template modification:

XML:
  <modification type="public" template="helper_js_global" modification_key="dbtech_ecommerce_total_unread" description="Update the &quot;total unread&quot; counter" execution_order="10" enabled="1" action="str_replace">
    <find><![CDATA[$xf.visitor.conversations_unread + $xf.visitor.alerts_unread]]></find>
    <replace><![CDATA[$0 + $xf.visitor.getDbtechEcommerceCartItems()]]></replace>
  </modification>

getDbtechEcommerceCartItems is a custom extension to XF\Entity\User:
PHP:
    public function getDbtechEcommerceCartItems()
    {
        if ($this->user_id)
        {
            return $this->dbtech_ecommerce_cart_items;
        }
        
        return $this->app()->request()->getCookie('dbtechEcommerceCartItems', 0);
    }
(Defining this function as a getter caused conflicts, hence why I call the function directly.)

During 80% of the add-on uninstallation process, the following was displayed on the screen:

Code:
Template public:helper_js_global: Method getDbtechEcommerceCartItems is not callable on the given object (XF\Entity\User) (src\XF\Template\Templater.php:932)
Template public:helper_js_global: number_format() expects parameter 1 to be float, string given (src\XF\Language.php:804)
Template public:helper_js_global: Method getDbtechEcommerceCartItems is not callable on the given object (XF\Entity\User) (src\XF\Template\Templater.php:932)
Template public:helper_js_global: A non-numeric value encountered (internal_data\code_cache\templates\l1\s0\public\helper_js_global.php:109)

This would be displayed everywhere, front-end and AdminCP alike.

If possible, perhaps reverting template modifications should be moved to the start of the uninstall process so that such errors are not stuck waiting for templates and phrases to be deleted first (of which my mod has very, very many :P)


Fillip
 
This issue also appears during install, but for a brief period of time. It appears as if template mods are applied before class extensions, which also causes this issue.

I've worked around it by using (callable($xf.visitor, 'getDbtechEcommerceCartItems') ? $xf.visitor.getDbtechEcommerceCartItems() : 0).


Fillip
 
@DragonByte Tech this is related to the is_processing flag causing your add-on's class extensions and such to not be loaded (which are near instant vs template recompiling) while install/upgrade/uninstall process happens.

This is actually really horrible that an upgrade puts your add-on into a half-disabled state where the code isn't running but the template modifications still exist. And if anything goes wrong in the upgrade process, your add-on will likely be stuck in a half-disabled state with XenForo now permanently throwing away error messages.
 
At this point, it's very unlikely that anything will change here. It's very important that the code involved in an add-on is disabled until we can guarantee that all of the extensions and custom code are loaded or it can cause situations where add-on actions can't be processed. The template modification situation isn't really ideal, though as noted, the time involved to resolve that is potentially unknown and could itself cause other issues as well.

As you mentioned, it is possible to suppress these errors in your code. It's also worth noting that these errors are only actually displayed in debug mode.
 
Top Bottom