Placeholder modifiers - output modifiers treating an integer strangely

I love to use output modifiers just so I can keep snippet logic to a minimum. However I've run into something strange.

Placeholder is being set in a snippet via $modx->setPlaceholder();
Value is an integer.

When placeholder is called in a chunk with placeholder tag, it displays the integer.

When using a comparative operator or math operator, it's treated as 0.

Placeholder set in snippet with value of 5.

[[+placeholder]] displays 5
[[+placeholder:decr]] displays -1

I imagine this has something to do with parsing order. I've called the placeholder cached or uncached, same difference. Snippet is being called uncached at the resource level.

Any ideas would be greatly appreciated!

You could try this, though I don't think it will make any difference:



Some output modifiers are cranky when they don't get all their expected arguments. Doing things like this in a dedicated snippet will generally give you faster page loads, though.

Bob- thanks again. This seems to be a bug in 2.3.1. that worked without issue in the last 2.2.x (can't remember what that last revision was).

Basically it's a nesting issue.

I have a snippet that calls a chunk through getChunk. Placeholders are set in that chunk by the snippet that are evaluated with modifiers.

The chunk that was called through getChunk with the evaluative modifiers is then set to a placeholder in the snippet.

That placeholder is then referenced in another chunk that is called in a resource.

I know this is rather deep nesting. The weird thing is I didn't have this issue until I updated to 2.3.1 - the evaluative modifiers worked liked a charm!

I had to move the evaluated placeholders "up" a level in this hierarchy of nesting to fix it in the last occurrence, but it's reared it's ugly head again and the rework at this point would be something I didn't want to have to do at this point to "move it up".

Wondering if I should submit a bug report?

Thanks!

Nesting issues are kind of on the border between bugs and non-bugs. For someone to try to fix that "bug," they would have to duplicate your exact nesting pattern, then try many permutations of cached versus uncached tags to see if it would work with any of them, then (if none worked), try to create a fix to the parser that wouldn't break any other code. It's probably not going to happen.

This isn't necessarily relevant, but you might find it interesting: http://bobsguides.com/blog.html/2014/05/15/dont-be-a-nester/.