Uncached placeholders nested in a cached element are not processed properly

[yoleg]

yoleg created Redmine issue ID 3857

When using placeholders (such as those produced by a formit form submission to place errors), inside of a cached snippet output (such as an &then clause from the If snippet), placeholders are properly processed. However, when using them in the exact same place with output filters or inside of another snippet, they fail to process.

I have had this issue with multiple snippets (as posted here: http://modxcms.com/forums/index.php/topic,61050.msg347894/topicseen.html#msg347894), but here is the SIMPLEST way I can reproduce it:

Make an uncached formit call that uses a cached chunk to output the fields:

[[!FormIt? &hooks=`spam,redirect` &redirectTo=`14` &submitVar=`submitForm` &validate=`testing:required`]]

[[$field? &name=`testing` &req=`1` &type=`text`]]

?

Make sure you have a css class that allows input.error to be highlighted, since we will be using the :notempty output filter to change the field's class to error (e.g. input.error {background: red;}).

Here is the field chunk:

[[+req:notempty=`* `]][[+message:default=`[[+label:default=`[[+name:replace=`_== `:ucwords]]`]]`]]
[[If? &subject=`[[+type]]` &operand=`text` &then=`
     
     [[!+fi.error.[[+name]]]] 
`]]

You will notice that there is an If call in the chunk, and that the [[!+fi.error.[[+name]]:notempty=error]] is inside of the &then parameter. If can be called cached or uncached; as long as the [[$field]] chunk is called cached as in the example above.

Preview the page and submit the form leaving the testing field blank! You will see that [[!+fi.error.[[+name]]]] processes correctly, even though [[!+fi.error.[[+name]]:notempty=error]] does not process. Calling the [[!$field]] chunk uncached solves the issue.

[[$field]] logically needs to be cached because there is no reason to re-create a text field every single time the form is processed. The error codes need to be re-created, but the <input type="text" id="testing" class="text"... /> should not need to be recreated every time (in other words, partial caching should work in this case).

Again, I've been having this issue with other snippets, so if this is actually not an issue and part of the design, I would appreciate a work-around.

[opengeek]

opengeek submitted:

This is because the field chunk is being processed (and cached) before your uncached Snippet. That will never work. You would have to uncache them both or have the Snippet return the output from the Chunk so it was processed in the proper order.

[yoleg]

yoleg submitted:

If that is the case, then this is still a bug, because caching is VERY inconsistent.

[[!+fi.[[+name]]]]

will process correctly every single time, but

[[!+fi.[[+name]]:notempty=` error`]]

will not process at all - in the exact same location! The only difference is the addition of an output filter.

[opengeek]

opengeek submitted:

FWIW, this is a confirmed bug with how output filters are processed in general.

[yoleg]

yoleg submitted:

This does not just affect output filters. At least in 2.0.8, this also sometimes happens when a placeholder is used inside of a snippet parameter.

Also, this may or may not be related, but in Revo 2.1 RC3, the problem seems to have gotten worse and affects even uncached elements. I called getResources uncached. The image tv [[[[+tv.thumbnail]]]] in the template chunk produced the URL as expected, but when I tried to use the phpthumbof output filter, I could not get it to work: [[+tv.thumbnail:phpthumbof=w=50]] and [[!+tv.thumbnail:phpthumbof=w=50]] both didn't work, and I had to use getResourceField to fix the problem.

However, my original example (where the placeholders are FormIt error codes) still works fine uncached in 2.1 RC3.

[yoleg]

yoleg submitted:

Correction: Sorry, I meant 2.0.7, not 2.0.8: "At least in 2.0.7, this also sometimes happens when a placeholder is used inside of a snippet parameter."

[gadamiak]

gadamiak submitted:

I can't confirm the above, as it works for me. However, I encountered other kind of cache issues, which I guess may be related. See #4376.

[opengeek]

opengeek submitted:

This was a bug related to modPlaceholderTag->process() calling filterOutput() when the placeholder is null. Fixed for 2.1.0-pl.