My logs are filling up with this error:
(ERROR @ /www/core/model/modx/modparser.class.php : 541) Could not find snippet with name #4434.tv.footer_type:is=`condensed`:then=` . . .
In the chunk, here’s the code:
[[#[[UltimateParent]].tv.footer_type:is=`condensed`:then=`<footer id="footer" . . .
I have FastField installed on this site, and it is actually working just fine. The condition is run successfully, and the HTML after “then=`” shows up as expected in the footer. If I put “[[#[[UltimateParent]].tv.footer_type]]” in the template, the correct value gets displayed. FYI, there is quite a large chunk of HTML after “then=`”, and there is a smaller chunk after “:else=`” further down the chunk. Should that matter?
So why all the errors?
If I do this instead, then there are no errors:
[[#[[UltimateParent]].tv.footer_type:toPlaceholder=`footertype`]] [[+footertype:is=`condensed`:then=` . . .
Using MODX 2.8.6, PHP 7.4.33, hosted on MODX Cloud.
It could be, that the MODX parser gets ‘confused’.
Does the same error occur when you (temporarily) change the code in
:else=`...` to something simple?
You could also try using this code, by moving the footer markup into actual chunks:
Do you use the actual FastField extra, or just the same functionality from pdoTools.
FastField actually replaces the MODX parser with its its own class that extends the MODX parser class. I’ve always thought that a small dedicated snippet is a better alternative for getting fields from other resources.
This is from the MODX docs:
modParser is modified in new version of MODX, the behaviour of [the FastField] plugin will be unpredictable.
So, with FastField, any MODX upgrade could potentially break your site.
pdoTools does the same. And a majority of MODX sites use that extra.
Thanks for the info. I wasn’t aware of that, though I’ve never seen a complaint about problems caused by pdoTools. I’ve read about a number of issues with FastField.
Yes, simple versions work.
FastField extra. I didn’t know pdoTools has this capability. So, if I have pdoTools installed (which I do), then I don’t need FastField? Any difference in the usage? And if the usage is the same, which extra takes precedence?
I don’t think so.
There is a system setting
parser_class_path as well). If it’s set to “fastFieldParser”, then the parser from the extra “FastField” is used. “pdoParser” is the parser from pdoTools. The value is probably set to the extra you installed last.
So it’s likely a parser issue. (Could even be the MODX parser.)
Is there maybe an uncached tag, that’s inside the
It’s probably best to just implement the workaround and move on.
Unless I’m mistaken though, FastField has some additional functionality not supported by pdotools, specifically in regards to getting global array values,:
Blockquote Return the value of $_POST[‘myVar’]:
Supported global arrays:
$_SESSION. The type of array after # is case-insensitive. The name of array element is case-sensitive. You should use uncached tag, eg.
[[!#get.name]], for cached resources.
Superglobals work in pdoTools as well.
To quote from the pdoTools documentation:
I think many people know about interesting component fastField, which adds the processing extra placeholders to the system, like
[[#15.pagetitle]]. This functional has already been added to pdoParser by the permission of the author and it has even been a bit expanded.
There were a couple of uncached snippets in the chunk. Changing them to cached didn’t make any difference.
pdoTools was set as the parser_class_path. Changing that to fastField made all the error messages go away. So the problem must have to do with how pdoTools is doing the parsing.
Can you tell if pdoTools resets the
parser_class_path when it’s installed, or maybe when you activate the plugin? The former would be bad behavior imo.
Yes, that’s exactly what happened. Then, after reinstalling FastField, the parser_class_path was changed bacak to FastField.