• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.

As designed Property access error is not affected by conditions.

CyberAP

Well-known member
#1
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:

Code:
<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

XenForo developer
Staff member
#2
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

Well-known member
#3
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

XenForo developer
Staff member
#4
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

XenForo developer
Staff member
#5
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

Well-known member
#6
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:

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

Chris D

XenForo developer
Staff member
#7
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

Well-known member
#8
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.