XF 2.0 Unsupported operand types in internal_data/code_cache/templates/l1/s2/public/forum_view.php on line 22

[VergilPrime]

My website

When accessing any forum I get the following error:

An exception occurred: [Error] Unsupported operand types in internal_data/code_cache/templates/l1/s2/public/forum_view.php on line 22

XF\Template\Templater->{closure}() in src/XF/Template/Templater.php at line 1250
XF\Template\Templater->renderTemplate() in src/XF/Template/Template.php at line 24
XF\Template\Template->render() in src/XF/Mvc/Renderer/Html.php at line 48
XF\Mvc\Renderer\Html->renderView() in src/XF/Mvc/Dispatcher.php at line 332
XF\Mvc\Dispatcher->renderView() in src/XF/Mvc/Dispatcher.php at line 303
XF\Mvc\Dispatcher->render() in src/XF/Mvc/Dispatcher.php at line 44
XF\Mvc\Dispatcher->run() in src/XF/App.php at line 1931
XF\App->run() in src/XF.php at line 329
XF::runApp() in index.php at line 13

 

[Chris D]

The error suggests that something in your forum_view template is performing an invalid mathematical operation - such as trying to add an integer to a string or similar.

First step is to disable all add-ons and try again, then if it persists, also access the forum using an unedited, default XF style (you can create a new style with no parent to get this back).

 

[Jon W]

@VergilPrime and I managed to solve this, but for the benefit of other users I'll post here too.

The issue is due to a change in the forum_view template in the latest version of XenForo, which we have reflected in the latest update to our themes.

If you update your themes to our latest version without updating your XenForo version, you will therefore get the above error.

@Chris D I appreciate that this is kind of inevitable when you make updates, but is there anything you guys can do to make sure that such backwards incompatible changes are avoided as this has affected a lot of our customers.

 

[Chris D]

Can you elaborate on the specific change, and the fix you implemented for it?

Difficult for us to answer without context

 

[Jon W]

In the latest update, the following change was made in the forum_view template.

From:

<xf:macro template="metadata_macros" name="canonical_url"
    arg-canonicalUrl="{{ link('canonical:forums', $forum, {'page': $page}) }}" />

to:

<xf:macro template="metadata_macros" name="canonical_url"
    arg-canonicalUrl="{{ link('canonical:forums', $forum, $canonicalFilters + {'page': $page}) }}" />

Since $canonicalFilters presumably doesn't exist in XenForo 2.0.11 and below, if you make the same template change in older versions of XenForo it breaks your site.

I'm not really sure what could be done better, so I guess I'm just throwing it out there in case you have any good ideas.

 

[oman]

@VergilPrime and I managed to solve this, but for the benefit of other users I'll post here too.

The issue is due to a change in the forum_view template in the latest version of XenForo, which we have reflected in the latest update to our themes.

If you update your themes to our latest version without updating your XenForo version, you will therefore get the above error.

@Chris D I appreciate that this is kind of inevitable when you make updates, but is there anything you guys can do to make sure that such backwards incompatible changes are avoided as this has affected a lot of our customers.

I also strongly believe here that you should ensure that your add ons / styles have appropriate measures (when someone goes to update your add on / styles to benefit from improvements without updating their XenForo version) in place to prevent throwing an error that breaks access to nodes entirely.

I have a client who also experienced this error and it has caused a massive inconvenience to their site.

 

[Jon W]

I also strongly believe here that you should ensure that your add ons / styles have appropriate measures (when someone goes to update your add on / styles to benefit from improvements without updating their XenForo version) in place to prevent throwing an error that breaks access to nodes entirely.

I have a client who also experienced this error and it has caused a massive inconvenience to their site.

I don't think it's going to be possible for us to do this. It's almost inevitable that if you upgrade your theme to a version that doesn't match your XenForo version something is going to break, so we would never recommend doing that.

I'm sure @Chris D would agree with that.

I guess we should be making it a little more obvious that customers shouldn't be doing this, but I wonder if perhaps this is something that needs to come from higher up (i.e. from XenForo).

 

[Xon]

Since $canonicalFilters presumably doesn't exist in XenForo 2.0.11 and below, if you make the same template change in older versions of XenForo it breaks your site.

Add this before the link statement;

<xf:set var="$canonicalFilters" value="{{ $canonicalFilters ?: [] }}" />

Alternatively amend the link statement to be backwards compatible;

<xf:macro template="metadata_macros" name="canonical_url"
    arg-canonicalUrl="{{ link('canonical:forums', $forum, ($canonicalFilters ?: []) + {'page': $page}) }}" />

 

[Mike]

Unfortunately, generally speaking, it's hard to prevent issues if styles are installed for an incorrect version. Notably, this issue appears to be related to installing a 2.0.12 style on an earlier version of XF. A more extreme version would be installing a 2.1 style on 2.0. We can't do much (other than maybe case-by-case adjustments) to resolve issues that this might cause.

However, 2.1 now tracks the version a style or language is exported from (XF or add-on version as appropriate) and does some additional checks that may block import of the XML file by default. Relevant to this case, it won't let you install a style/language built from a newer version than what you have installed. There are also a few additional checks we've added (including some overwrite-related things) that should help prevent accidents. If you have a reason to (or if one of the results is a false positive), we do give you the option of bypassing the checks and doing the import anyway.

 

[Jon W]

However, 2.1 now tracks the version a style or language is exported from (XF or add-on version as appropriate) and does some additional checks that may block import of the XML file by default. Relevant to this case, it won't let you install a style/language built from a newer version than what you have installed. There are also a few additional checks we've added (including some overwrite-related things) that should help prevent accidents. If you have a reason to (or if one of the results is a false positive), we do give you the option of bypassing the checks and doing the import anyway.

I didn't know this. This sounds perfect.

 

[Mike]

When I said "now", I meant "now, because I've just committed changed to do it"

 

[Jon W]

When I said "now", I meant "now, because I've just committed changed to do it"

Even more perfect. Thanks for that!