Output modifiers, parseChunk and getChunk

I noticed a strange behavior in 2.2.0-pl2. If I use $modx-> parseChunk('chunkname') in a snippet, and try to add an output modifier to a placeholder in "chunkname", the output modifier doesn't work (in fact, it outputs nothing at all where the placeholder should be). If I do the same thing with $modx-> getChunk('chunkname');, it works great.

Not really a big deal. Just curious if anyone else has noticed or can reproduce this? Is this by design, or a bug? What's the reason for having two API calls that do basically the same thing?

I think parseChunk() is meant to be used internally by MODX. There's no reason I know of not to use getChunk().


------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

Did getChunk exist in pre-Revo days? Because I think I picked up the (apparently bad) habit back under Evo. Specifically, I used this tutorial a lot, which uses it: http://wiki.modxcms.com/index.php/DB_query_and_Placeholders

Yes, getChunk() has been around for a long time. You do know that you can send an associative array of placeholders->values as a second argument to getChunk(), right?




I think I was wrong about parseChunk(). The difference is that parseChunk() allows you to set the placeholder tag style and getChunk() doesn't.

parseChunk() should still work as long as you either use standard placeholder tags or set the last two arguments correctly, but it may not have been updated correctly to handle output modifiers.






------------------------------------------------------------------------------------------
PLEASE, PLEASE specify the version of MODX you are using.
MODX info for everyone: http://bobsguides.com/modx.html

$result = $modx->getChunk('MyChunk', $fields); [ed. note: BobRay last edited this post 14 years, 6 months ago.]

Thanks; good info. Do you think the output filter issue is worth a bug ticket?

The difference between parseChunk and getChunk is that parseChunk simply does a str_replace on the values in the associative array you pass it. This is why output filters do not apply to it. In contrast, getChunk actually sets the properties you pass (and that are picked up from default properties and/or a property set) as placeholders (preserving any with the same key and restoring those after processing is complete) and allows the modChunk class to process() them (along with any other tags, filters, etc.).

The output filters in Revo are handled by the Element classes themselves when the process() method is called on them.

I'm not an OO expert, so this may be a silly question...but would that mean parseChunk is actually a little faster in situations where you don't need additional modChunk handling?

Quote from: aladage at Apr 12, 2012, 09:51 AM

I'm not an OO expert, so this may be a silly question...but would that mean parseChunk is actually a little faster in situations where you don't need additional modChunk handling?

Sort of, though this depends on the content of the Chunk. If there are other tags, then this method would simply displace the normal, recursive order of processing, delaying the processing of the other tags until after the method is completed. Ultimately, the processing time will end up about the same as you are not having to load any new OO classes when processing tags.

I suppose parseChunk might be useful in certain situations, but it was originally kept there only for backwards compatibility with Evo API calls.

I suppose parseChunk might be useful in certain situations, but it was originally kept there only for backwards compatibility with Evo API calls.

I thought that might be the case. Thanks for indulging my theoretical questions -- I have no qualms over using one over the other; I was just curious about the differences, and how there came to be two seemingly similar functions.