placeholder parsing - what's going on here?

☆ A M B ☆
450 Posts

jrotering Reply #1, 16 years, 1 month ago

If I set placeholder [[+site]] to ’2’:

[[+site]] // output = '2'
[[~[[+site]]]] // no output! Even though I have a published &not-deleted resource with ID 2

I’m thinking this has something to do with variable type. I wrote a snippet called ’echo’ that does a var_dump on the input variable, then on the input variable typecast to int:

<?php
//$e is the input variable
var_dump($e);
var_dump((int)$e);
?>

[[echo?&e=`2`]]

generates (as one would expect) this:

string(1) "2"
int(2)

[[echo?&e=`[[+site]]`]]

generates this:

string(9) "2"
int(0)

Okay, so... string(9) tells me that the placeholder hasn’t been parsed yet. The real output is string(9) "[[+site]]". But then later the [[+site]] is getting parsed to ’2’. Right?

I’m trying to set this placeholder at the top of my template code, with the ID of a certain ancestor resource that contains various subsite definition info... and then reference it throughout my template code.

Things like this won’t work right either:

[[Wayfinder? &startId=`[[+site]]`]]

Thoughts?

☆ A M B ☆
2,475 Posts

Everett Reply #2, 16 years, 1 month ago

Interesting. Good footwork there on researching the cause.

Do you know if the same behavior occurs if you use a template variable that you’ve set to return an integer? (I think you can do that), e.g.

[[WayFinder? &startID=`[[*my_int]]`]]

The parser in Revo works differently than in Evo.... but I don’t know the gory details.

Hosting stuff: http://fireproofsocks.com/
Coding stuff: http://craftsmancoding.com/
Blog stuff: http://tipsfor.us/

134 Posts

itWillBeOk Reply #3, 16 years, 1 month ago

Hi J,
i played around a little with placeholders and i can only confirm your observations.
another weird thing a noticed:
i set a placeholder [[+foo]] via a snippet / modx->setplaceholder

<?php
$modx->setPlaceholder('foo', 'xxxx' )

then i called a chunk

[[$chunk? &bar=`[[+foo]]`]]

inside the chunk i tried a very non-professional workaround. i thought instead of setting [[+foo]] to a number, why not set it to a string with the length of that number e.g. ’xxxx’ instead of 4 and then call [[+foo:length]] and hope this would return an actual number
my output was this:

[[+foo]]->[[+foo:length]] // xxxx->0  Placeholder has the right value, but no length
[[+bar]]->[[+bar:length]] // xxxx->8  Placeholder has the right value, but length is counting '[[+foo]]', not its value

This is also not what i would expect here.
No thoughts though.

@itWilllBeOK

24,544 Posts

BobRay Reply #4, 16 years, 1 month ago

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

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

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

☆ A M B ☆
450 Posts

jrotering Reply #5, 16 years, 1 month ago

Do you know if the same behavior occurs if you use a template variable that you’ve set to return an integer? (I think you can do that), e.g.

I’m pretty sure that works. I think the issue here isn’t so much placeholders-as-id’s or as ints, but that placeholders can’t be used in this manner at all because they aren’t getting parsed until after the containing snippet or link tag is parsed. It seems as though, for [[~[[+site]]]], for example, the outer tag is being parsed first and trying to make a link out of the unparsed string ’[[+site]]’.

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

I tried that too, and I don’t think it speaks to this particular issue.

☆ A M B ☆
2,475 Posts

Everett Reply #6, 16 years, 1 month ago

Here’s some other info I read in some other threads (I’m not mrhaw, so I don’t have the uncanny ability to have the bookmarks at my fingertips):

With the link ~tag syntax, here are a couple interesting things:

You can append parameters in a safe way just by adding them like this:

[[~123? &param1=`[[*my_val]]`]]

That avoids the problems that can occur if you’re trying to append parameters to a URL and you don’t know if the "?" has already been used or not (e.g. if FURLs aren’t enabled)... e.g.

// DON'T DO THIS:
[[~123]]?param1='[[*my_val]]

There was also another post out there with weird behavior if the first character of the URL was an integer, MODx would load up the resource with that ID (!), e.g.

http://yourmodxsite.com/1-I-can-type-whatever-i-want-here-and-it-will-still-load-page_id-1.html

It had to do with php’s intval() function:
http://modxcms.com/forums/index.php/topic,53586.msg309996.html

Anyway... seemed apropos to the discussion, so I thought I’d share.

Hosting stuff: http://fireproofsocks.com/
Coding stuff: http://craftsmancoding.com/
Blog stuff: http://tipsfor.us/

☆ A M B ☆
450 Posts

jrotering Reply #7, 16 years, 1 month ago

Bottom line seems to be this: setting placeholder ’site’, and then trying to make a link anywhere in your resource (directly in the resource or in any chunk used by the resource) like this:

[[~[[+site]]]]

results in this:

[2010-09-01 16:18:40] (ERROR) `[[+site]]` is not a valid integer and may not be passed to makeUrl()

Here’s my workaround:

Rather than doing this:

[[setPlaceholders]] // sets 'site' to a resource ID
[[$somechunk]] // contains [[~[[+site]]]]

...which doesn’t parse properly, instead do this:

[[setPlaceholders]] // sets 'site' to a resource ID AND sets 'somechunk' to $modx->getChunk('somechunk')
[[+somechunk]] // replaced with the chunk, but now the link/placeholder combo parses properly!

I’m not bright enough to explain exactly WHY this works, but it seems that when you use the API getChunk method, all of the placeholders are immediately parsed... but when you use [[~[[+ph]]]] directly within the content/chunk flow of the document, the [[~]] link tag gets parsed before the placeholder, resulting in an error.

Does this make sense? Or have I been staring at my monitor too long today?

24,544 Posts

BobRay Reply #8, 16 years, 1 month ago

Quote from: jrotering at Sep 01, 2010, 04:38 PM

Bottom line seems to be this: setting placeholder ’site’, and then trying to make a link anywhere in your resource (directly in the resource or in any chunk used by the resource) like this:
[[~[[+site]]]]
results in this:
[2010-09-01 16:18:40] (ERROR) `[[+site]]` is not a valid integer and may not be passed to makeUrl()

Is the snippet that sets the "site" placeholder above the tag? It looks like the placeholder tag is not being parsed in time.

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting

☆ A M B ☆
450 Posts

jrotering Reply #9, 16 years, 1 month ago

Is the snippet that sets the "site" placeholder above the tag? It looks like the placeholder tag is not being parsed in time.

It is - placeholders are being set by a snippet that is the very first thing in the resource.

This seems to affect placeholders when they are used inside a link tag, and as arguments to snippets.

It does not affect them when they are used inside a chunk tag. [[$[[+foo]]]] works as you would expect; [[~[[+foo]]]] does not, and neither does [[Wayfinder?&startId=`[[+foo]]`]].

24,544 Posts

BobRay Reply #10, 16 years, 1 month ago

I would say that qualifies as a bug, then. Would you file that using the bugs and requests link at the top of this page.

Did I help you? Buy me a beer
Get my Book: MODX:The Official Guide
MODX info for everyone: http://bobsguides.com/modx.html
My MODX Extras
Bob's Guides is now hosted at A2 MODX Hosting