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?
It could be, that the MODX parser gets ‘confused’.
Does the same error occur when you (temporarily) change the code in :then=`...` and :else=`...` to something simple?
You could also try using this code, by moving the footer markup into actual chunks:
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:
So, if 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.
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.
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?
There is a system setting parser_class (and 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 <footer>... markup?
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’]:
[[!#post.myVar]]
Supported global arrays: $_GET, $_POST, $_REQUEST, $_SERVER, $_FILES, $_COOKIE, $_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.
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.