Output filter bug???

Is this a bug...or am i missing something? I have a placeholder like so:

[[+vc.category.config.customFields.testField]]

It outputs perfectly fine (i can see the value on the screen). When i pass
an output filter to the placeholder:

[[+vc.category.config.customFields.testField:nl2br]]

The value returns nothing...it’s just empty...also a strlen returns 0.
Can i not do this? Or is this a bug?

Try calling it uncached: [[!+vc.category.config.customFields.testField:nl2br]]

That fixed it!

Can you please explain this behavior?

Quote from: b03tz at Nov 18, 2010, 07:44 AM

Can you please explain this behavior?

I think I can explain it, because I’ve been immersed in issues that look very familiar.

I’ll bet $5 that you are setting this placeholder with an uncached snippet.

What happens is, I think, output filters change the parse order of placeholders (and maybe other stuff too?). Ordinarily, when a placeholder gets to its turn in the parse order (during the first-pass, the ’cached tags’ pass), if it does not find a matching value it sticks around and waits for the second pass (the ’uncached tags’ pass) and tries again to find a matching value before the parser gives up and disintigrates it. But when an output filter is used, I think it is forcing the cached placeholder to be given its final evaluation on the first-pass. Since in your case (if I’m right), the placeholder has no value yet on the first pass, it returns empty.

I was experiencing this with :empty/:notempty filters (http://modxcms.com/forums/index.php/topic,57438.0.html)... but if it is happening with all filters, I wonder if we might want to consider it a bug - or at least something that users will need to be educated about.

Yes...i was using the placeholder in the introtext of a resource, but it got created
by a cached chunk (which had a uncached snippet call that set the placeholder).

So...

Resource -> introtext -> USED the placeholder
Resource -> content -> cached chunk -> uncached snippet -> setting placeholders

I hope this makes sence

If you call an uncached Snippet, it will be executed last in the parsing order.

If you have cached placeholders below that, they will be evaluated before that Snippet is executed - meaning they’ll get the last value that was stored in the cache by that Snippet previously (or empty, if not set yet).

If you want to call a Snippet uncached that sets placeholders, you need to make sure the placeholders are set to uncached as well:

Quote from: splittingred at Nov 18, 2010, 09:18 AM

If you call an uncached Snippet, it will be executed last in the parsing order.

If you have cached placeholders below that, they will be evaluated before that Snippet is executed - meaning they’ll get the last value that was stored in the cache by that Snippet previously (or empty, if not set yet).

Yes, but... if they evaluate as empty, they stick around and try again after the uncached snippet gets executed... *unless* they have an output filter, in which case they do get processed, game over, you lose.



So: Is it a bug that empty cached placeholders don’t disappear after the first pass? Or is it a bug that attaching an output filter does force them to be evaluated after the first pass? Or are neither of those things bugs.

I await the wisdom of the gods at the top of Mount MODx.

In general, any content in a placeholder that you think *might change dynamically* should be uncached. For example, your empty demo:



This means that this could *sometimes* be empty, and sometimes not. Why would you ever want that cached? That would eliminate the point of the filter.

Sometimes, filters can be done on a cached placeholder - but only if you’re calling the Snippet that sets them cached as well. Otherwise, you’re performing an illogical maneuver - trying to cache statically something that was never meant to be static.

In general, the rule is: If you set a placeholder in an uncached Snippet, the placeholder needs to be uncached as well if you expect the content of the placeholder to differ, ever.

Aaah! That was a fun read

Thanks guys...thanks alot.

Bug or no bug, this should be documented in the Output filters section in the RTFM

In general, the rule is: If you set a placeholder in an uncached Snippet, the placeholder needs to be uncached as well if you expect the content of the placeholder to differ, ever.

I understand that that’s the rule, the best practice, and I’ll do my part to make that clear whenever I’m teaching anyone how to work with placeholders.

However - the fact remains that if you break this rule, and do use cached placeholders after an uncached snippet (whether intentionally or unintentionally), you will have no problems at all UNLESS you bring output filters into the equation. Plain unfiltered cached placeholders will work. And when you are developing, and your placeholders are getting values as you expect them to, and everything is humming along smoothly, and then you add an output filter and everything seems to break... it can be rather disconcerting and frustrating.

Sometimes people fall into a "best practice" because there is an immediate disincentive to using the "not-so-good practice". Here that is not necessarily the case - you can easily fall in to a "works just fine" practice that breaks later at an inopportune time, unless you go in to it upfront with the knowledge of how not to shoot yourself in the foot.

For the record, if you have a bunch of placeholders after your snippet, and you need them all to be uncached, I’d say a better practice is to put them all in a chunk and just call that chunk uncached. Or better yet have the snippet return the chunk (then you don’t need to worry about cached/uncached at all).