Snippet with Placeholder as Parameter

Is it possible to have a Snippet that takes a placeholder as a parameters, as in:

[[mySnippet? &parameter1=`1` &parameter2=`[+myPlaceholder+]`]]

I have this and my parameter2 always comes in empty even though it should have a value.

Am I doing something wrong, or is this not possible?

Thanks!
Shaun

Followup: The issue appears to be with the fact that I have two instances of this snippet call in the same chunk, but with different parameters passed in.

If I break the calls into different snippets and hard-code the first parameter, the placeholder parameter works.

I just can’t seem to get any snippets that accept parameters to function properly when there is more than one of the snippet in the chunk.

Any ideas?

I am running evolution

I could be wrong, but I think it should work as long as the snippet that sets the placeholder comes before the one that uses it as a parameter.

If the page is cached, the second snippet should be uncached ( [!snippet!]). If the page is uncached, the snippet should be cached in Evo.

Quote from: BobRay at Jun 29, 2010, 06:58 PM

I could be wrong, but I think it should work as long as the snippet that sets the placeholder comes before the one that uses it as a parameter.

If the page is cached, the second snippet should be uncached ( [!snippet!]). If the page is uncached, the snippet should be cached in Evo.

Thanks for the response. Per my followup, I am able to get the placeholder parameter to work if I don’t put two instances of the snippet in the chunk. The problem happens when I put multiple instances of a snippet that has parameters in a chunk. The first instance of the snippet gets parsed, but without the placeholder parameter getting passed in, and the second instance of the snippet doesn’t get executed at all. If I remove one of them, the single snippet works perfectly. This has really got my scratching my head.

Thanks again for any help.

There are many instances in Evolution where the parsing order causes problems when you start nesting snippets and chunks and its often difficult to know what should be cached. Revolution is *much* more reliable in these kinds of situations because chunks and placeholders can be uncached, everything gets parsed when it should, and the cache control of individual elements is more independent.

I'm currently trying to use a placeholder as a snippet parameter, and while I can echo the string successfully, any PHP string operations fail because the target string suddenly becomes the placeholder tag itself, as in "[ [+email] ]" rather than the string it should have passed in.

Is there some special way I'm supposed to be passing in a placeholder like this? So far I've got:

[ed. note: davidsmith last edited this post 14 years, 6 months ago.]

As long as the placeholder is set when the Snippet is parsed, it should pass the value of the placeholder. Otherwise, the tag will remain until the final phase of parsing when unprocessed tags are removed.

I've recently started another thread which I now realise is the same problem:

https://forums.modx.com/thread/75390/email-tv-output-can-t-be-searched-by-strpos

In my post above, the bit in quotes was stripped when I posted the message. It was supposed to read "[ [+email] ]" but with no spaces. That other thread explains in more detail. The placeholder must surely be set because I can echo it successfully in my snippet, yet in the same script, the very next line,



...produces "%5B%5B%2Bemail%5D%5D" which is "[ [+email] ]" again. I need that not to be the case, and I really can't work out how it's possible. Similarly, I can't explode the email address using explode() because it won't find the @ sign in the string, even though echoing gives me the full and correct email address. [ed. note: davidsmith last edited this post 14 years, 6 months ago.]

BobRay has kindly explained my problem and suggested some very good solutions/alternatives in that other thread:

https://forums.modx.com/thread/75390/email-tv-output-can-t-be-searched-by-strpos

I now understand how it works, and have decided either a custom output filter, or more likely an existing email obfuscator plugin will do the job very nicely instead, the latter without the need to bother with any manual snippet calls.

While I seem to have the answers I need to proceed, I can't help wondering the implications of what you said last, OpenGeek:

As long as the placeholder is set when the Snippet is parsed...

Are you suggesting there's a way to get a placeholder parsed/evalutated/set before a subsequent snippet call? I can understand why my plan didn't work, but you seem to be implying that under certain conditions it might well have worked.

Quote from: davidsmith at Mar 27, 2012, 04:55 PM

While I seem to have the answers I need to proceed, I can't help wondering the implications of what you said last, OpenGeek:

As long as the placeholder is set when the Snippet is parsed...

Are you suggesting there's a way to get a placeholder parsed/evalutated/set before a subsequent snippet call? I can understand why my plan didn't work, but you seem to be implying that under certain conditions it might well have worked.

All tags nested within another as is the case here, are processed before the containing (outer) tag. So if your nested placeholder is not set by a Snippet or other Element property before encountering the Snippet with that placeholder as a property value, it will be passed as the literal tag string. It is assuming that if there is no value set for that placeholder, that you may intend to set it later so it skips it until a later pass. It's just a matter of following the source order, recursive, multi-pass parsing process.

Hope that helps clarify what I meant.