At sign (@) inside chunk parameter value nested into tag output filter breaks tag parsing

[juro]

Consider this content:

[[+xyz:empty=`
aaa
[[xxx? &x=`bbb@ccc`]]
ddd
`]]
eee

Supposed output should be:

aaa xxxSnippetOutput ddd eee

Instead it is:

aaa [[xxx? &x=`bbb eee

This works fine as expected:

[[+xyz:empty=`
aaa
[[xxx? &x=`bbbccc`]]
ddd
`]]
eee

At sign (@) inside parameter value breaks parsing, but only when nested inside output filter parameter value. Workaround here is to put inner tag inside separate chunk.
With some more complicated scenarios this even causes Server error with End of script output before headers: index.php in error log.
Clean MODx 3.0.2 install, the same with older 2.7.3

[halftrainedharry]

I can't reproduce the issue with the provided example content.

[smg6511]

I can not reproduce this either (on a local install of 3.0.3-dev). If there is in fact a reproducible bug, you're going to need to provide detail on your actual code, not just the pseudo code shown above.

[juro]

Thanks guys for your testing. The code above is not a pseudocode, but actual code, the simplest version that demostrates problem. Snippet xxx don't have to even exist, placeholder xyz never gets replaced with value. I put this code into new resource with no template to avoid any other factors. The same behaviour on fresh 3.0.2 and older 2.7.3.
Originally we had problem with combination of Formit (that have email adresses as parameter values) and ContentBlocks (that wraps content with conditional output defined in Layout). So at first I blame one of them, but then stripped it down to the code used above. No specific snippets, no plugins, no template.
I will investigate further, the only thing that comes to my mind is PHP version. We are on 7.2.

[halftrainedharry]

Snippet xxx don't have to even exist

OK, I can reproduce it now (MODX 3.0.2, PHP 7.4) but only if the snippet "xxx" doesn't exist.
If the snippet "xxx" exists, everything works correctly.

[juro]

Oh, at least we are moving forward. I can confirm that when snippet exist, it works correctly. I still considers this to be core MODx bug. Probably it wouldn't impose problem on most sites, but have some implications in more complicated scenarios, like ContentBlocks.
When saving resource with CB, output modifiers on placeholders are parsed, but snippets are not. It is somehow similar to non-existent snippet (because at that moment it is not parsed) inside parsed output modifier.
Other workaround could be to replace output modifier with snippet call, unfortunately this is only possible with user modifiers, not build-in.

[Mark-H]

Think I have a fix. Will report back in a bit.

[Mark-H]

See potential fix at #16322 - please test and report back. That PR is surfacing a potentially different problem related to property sets that I haven't figured out yet though.

[smg6511]

Just curious — is it necessary to support the ability to call a non-existent snippet? Or put differently, what's the use-case for being able to do so?

[Mark-H]

The use case is not breaking the parsing if a snippet doesn't exist.

[smg6511]

Fair enough ;-)

Is there any/sufficient error reporting when a non-existent snippet is called? I know this would be a different issue if the answer were "no."

[juro]

Agree with Mark, parsing should be done right even if snippet doesn't exist. On very complex sites we dynamically build chunk and snippet names, e.g. from context settings. So, in some context we call a different snippet than in others.
For example:
[[mysnippet_[[++contextspecificsuffix]]]]

In this case sometimes no snippet should be called and of course should not break page.
Will try Mark's fix later today

[smg6511]

Not disagreeing, just wanted to understand the motivations. I too have set up dynamic tags like that of your example, but have never done so where the resulting tag calls a snippet that might not exist. I've more so used that strategy with chunks that pull up different variations of a block of code depending on a certain context/condition.