placeholder parsing - what's going on here?

This is not a bug actually. In order for a placeholder to be effective when nested inside other tags, that placeholder must already be set. This is simply a result of parsing order. Always set global placeholders before anything else in your template and you’ll never go wrong.

How do you set the global placeholders in your template? Aren’t those system settings that are already present?

Always set global placeholders before anything else in your template and you’ll never go wrong.

I believe that’s exactly what I’m doing, and I’m still going wrong.

Try this experiment:

snippet ’setPlaceholders’:


chunk ’html’:


Now create a resource that looks like this:


You will get this output (well, I do anyway):


And an error is generated: (ERROR) `[[+site]]` is not a valid integer and may not be passed to makeUrl()

Now change the setPlaceholders snippet to look like this:



And now the output is as you’d expect:

I’m trying to reproduce this, but no luck so far; it always seems to return the proper data. Any additional information about this Resource you can think of that might be relevant?

I’m trying to reproduce this, but no luck so far; it always seems to return the proper data. Any additional information about this Resource you can think of that might be relevant?

I’m working on that right now. I tried to boil the example down to the bare essentials... but when I try it that way, I can’t replicate the error either. I’ll have to try and figure out what else might be going on here.

I think I’ve got it figured out - the problem happens when setPlaceholders is called uncached (which is how I was calling mine).


That should replicate what I’m seeing.



I guess the rule here is, if you set the placeholder in an uncached snippet, you have to set the link tag to uncached also (or the chunk that contains it).

This is why properties can now be applied to any tag, i.e. instead of having some setPlaceholder API call separate from your Chunk, you can simply do:

where site is perhaps a system and/or context configuration setting with a default of 2 if nothing is set. Or:

where site is a template variable...

Ahem ...

I’m not sure if it will help you, but you can set *any* tag in Revo to be uncached with !:

[[!$chunkName]]
[[!+placeholderName]]

I’m not sure if it will help you, but you can set *any* tag in Revo to be uncached with !:

[[!$chunkName]]
[[!+placeholderName]]

At the time I had tried

[[!setPlaceholders]]
[[~[[!+site]]]]
(which doesn’t work)

But hadn’t tried

[[!setPlaceholders]]
[[!~[[+site]]]]
(which does).

I’m feeling silly now that I didn’t use the [[$html?site=`[[snippetToGetSite]]`]] method. Because of the strange issue, I ended up filling my html with placeholders and setting them all within setPlaceholders. But all I originally wanted to do was get the id value of "site" (a particular ancestor document that sets a bunch of TVs that define the look of the given subsite) and pass that to various chunks and snippets. I think I’ll go back to that approach now.

I’m still not entirely sure I understand why setting the placeholder in an uncached snippet causes [[~[[+ph]]]] to parse wrong. But at least I know how to do what I wanted to do in the first place.

Glad you got it sorted.

Would it make sense to create an independent property set with the values you need and just get them from there? They would be available with tags and with $modx->getOption() in code.