Help with nested backticks in pdoTools

I’m working on the new version of GoRevo. I translate the Evo if snippet to a new snippet called EvoIf, which is a version of the Evo snippet I created that works in Revolution. In the Evo bootstrap template (and I assume in some people’s Evo sites), there is code like this:

[[EvoIf? &is=`[[*id]]:!=:[[++site_start]]` &then=`
    [[pdoCrumbs?
       &outputSeparator=` > `
       &tpl=`@INLINE <a [[+classes]] href="[[+link]]"> 
            [[+menutitle]]</a>`
       &showDeleted=`0`
       &hideContainers=`0`
       &showUnpublished=`1`
       &homeCrumbTitle=`HOME`
       &showHomeCrumb=``
       &showCurrentCrumb=`1`
     ]]
`]]

The code fails. I’m pretty sure it’s because the first pdoCrumbs backtick is interpreted as a closing backtick for the one in the
&then property.

Is there some alternative character that can replace the backticks in the inner snippet? I couldn’t find anything in the pdoTools docs.

I ran your code in MODX 3.0.4 and it seems to work OK. I don’t think there is a problem with the backticks.


But to make sure, that pdoCrumbs only gets executed, when the condition in &is is met, you could do your own character substitution in the snippet “EvoIf”.
For example like this:

// In the template: Backticks replaced with °; square brackets in the property &then replaced with curly brackets
[[EvoIf? &is=`[[*id]]:!=:[[++site_start]]` &then=`
    {{pdoCrumbs?
       &outputSeparator=° > °
       &tpl=°@INLINE <a {{+classes}} href="{{+link}}"> 
            {{+menutitle}}</a>°
     }}
`]]
// --- In the snippet "EvoIf" ---
...
$then = str_replace(["{{", "}}", "°"], ["[[", "]]", "`"], $then);

You’re correct about it not being the backticks (which makes sense because tags are processed from the inside out).

I re-ran the import on a fresh install of Revo and the both snippets work fine. I think the actual problem turned out to be a flaw in the first Revo site. I thought the site_start System Setting pointed to a non-existent page, but setting it to 999 and clearing the cache manually didn’t cause any problems, so now I have no clue what caused the problem. :frowning: