As designed Property access error is not affected by conditions.

[CyberAP]

If we have a template that requests some property that is not available (for example with xen: property tag) — we'll get an error (only in debug mode).
But creating a condition that checks if that property exists doesn't help that:

<xen:if is="{xen:property someProperty}">{xen:property someProperty}</xen:if>

I think this should be fixed because we don't actually call that property.

 

[Chris D]

The if statement needs to evaluate the value of the components used in the condition, to do that it needs to know the value of any components, therefore, technically, it is called and it is therefore behaving as expected.

What exactly is the use case, here? You may need to find another workaround.

 

[CyberAP]

The if statement needs to evaluate the value of the components used in the condition, to do that it needs to know the value of any components, therefore, technically, it is called and it is therefore behaving as expected.

What exactly is the use case, here? You may need to find another workaround.

I need to make a support for an addon, if it's not installed I get this error in debug mode.

 

[Chris D]

You may have access in the template to $xenAddOns in which case you can check if the add on is installed that way and use that as your condition. If there's an option in that add on (that perhaps always needs to contain a value if the add on is to function correctly) then you could use that. Worst case scenario you could have a switch in your add on that specifically needs to be enabled to support that add on.

 

[Mike]

As Chris says, this is generally expected. You're asking if there's a value for the property, which is different than asking for property existence. That would need another function (with distinct behavior). That would be best covered in a suggestion I believe.

 

[CyberAP]

You may have access in the template to $xenAddOns in which case you can check if the add on is installed that way and use that as your condition. If there's an option in that add on (that perhaps always needs to contain a value if the add on is to function correctly) then you could use that. Worst case scenario you could have a switch in your add on that specifically needs to be enabled to support that add on.

I tried this one to check if it works and it didn't:

<xen:if is="{$xenAddOns.XenForo}">Custom code</xen:if>

 

[Chris D]

Technically, XenForo isn't an installed add-on, so that would be generally expected. That said, I just checked in more detail, and CssOutput.php doesn't pass the add-ons cache to the CSS templates. You can use {$xenOptions} there, though, so if the add-on has an option that may indicate the add-on is enabled, then you could use that.

 

[CyberAP]

Technically, XenForo isn't an installed add-on, so that would be generally expected. That said, I just checked in more detail, and CssOutput.php doesn't pass the add-ons cache to the CSS templates. You can use {$xenOptions} there, though, so if the add-on has an option that may indicate the add-on is enabled, then you could use that.

Thanks, solved now with an isset() check.