Nested Snippets and Caching

Hey guys, I’m having a seemingly caching-related issue after upgrading from MODx 2.0 to 2.1. It seems that nested snippets are being cached, even if they are called uncached... For example, I have a side navigation menu with the first-level navigation "categories". For each category you can click a button to load the child resources in a sub-menu. What I previously did was use a single resource (cached) which combined the getResources snippet and the getReqParam snippet to load the appropriate children.

This worked flawlessly in 2.0:



But in 2.1 it seems that the result from the first execution is cached, and the same child resources are loaded upon each request. I’ve also tried calling getResources cached but I get the same result. The only way to get the correct behavior to work is to call the entire resource uncached... which isn’t ideal, because in 2.0, after the child resources for a parent were loaded once, any consequent requests for those child pages would load from the cache and be quite speedy.

As a note, I’ve also tried this with Wayfinder, with the same result. So at the moment it seems that it’s a caching issue. am I doing something wrong, or is this the intended behavior in 2.1?

Thanks!

The only thing cached is the getResources call which is not evaluated again because it is being cached. If this worked before, IOW the non-cacheable nested tag prevented the getResources call from being cached, then it was a bug.

But even if getResources is called uncached, it still ends up being cached after the first request (I should have mentioned that in my first post). The only way to make this work now is to set the resource uncacheable. Something is being cached - either the getResources snippet, or the nested getReqParam call, I’m not sure which.

This was indeed a bug when nesting non-cacheable tags within cacheable ones. The non-cacheable output was being cached into the $modx->resource->_content. This has been fixed for 2.1.2-pl, due shortly. Please see issue #5152 for details.

Ah, that’s great! Thanks OpenGeek, I’m looking forward to 2.1.2 when it’s released!

Sorry to dredge this back up, but after upgrading to 2.1.2, there is still some "strange" behavior regarding nested tags.

1) Take the nested tags in my first post. After upgrading to 2.1.2, both tags must be called uncached, or the content seems to be cached. Combinations I’ve tried:

getResources cached, getReqParam cached -> cached (expected)
getResources uncached, getReqParam cached -> cached (?)
getResources cached, getReqParam uncached -> cached (expected)
getResources uncached, getReqParam uncached -> uncached (expected)

Why is the content cached when getResources is called uncached and getReqParam is cached? Is this the expected behavior in 2.1 now?

2) To bring up my original point (first post): in 2.0, using my original tag calls (getResources cached, getReqParam uncached), the output of each result set seemed to be cached, while still displaying the requested child documents for each parent. So my menu looked something like:

Parent 1 (id: 5)
Parent 2 (id: 6)
Parent 3 (id: 7)

Clicking on parent 1 sends a request to resource 20 whose content is the getResources/getReqParam combo. It loads the children for resource 5. Ditto for resource 6 and 7 (they all use resource 20 for AJAX calls).

I know *something* was cached, because the AJAX calls would complete noticeably faster the second time for each parent - especially for parents with many children (100+) - but it seems like this behavior is no longer possible in 2.1. Any ideas?

3) I use getResources (cached call) to display news on my main page. The chunk I use looks like this:


In MODx <= 2.1.1 this worked just fine. However, now, I’m having an issue with tolinks... This block completely disappears (as if it gets eaten by the parser):

This block seems to just disappear - even after adding a :default=`I’m Empty` condition results in nothing being output. The rest of the chunk displays fine. If I move the tolinks snippet outside the [[+tv.tags:notempty=``]] condition (eg just after that tag) everything works fine. It just seems odd that a snippet would break an output modifier like this.

1. Right, uncached tags cannot be processed until all outermost cacheable tags have been processed and stored for caching. This is the bug that was fixed. The problem is, if you process those nested non-cacheable tags when cacheable tags are being processed, then the non-cacheable tag is cached as well. You were taking advantage of a feature enabled by this bug.

2. Not sure why the output filter would stop working; no changes were made in processing those in 2.1.2 from 2.1.1.

Ok, that makes more sense - I was still thinking in pre-2.1 caching terms. Thanks for clearing the confusion up!

It just seems odd that *something* seemed to be cached previously in 2.0 (maybe the dataset, rather than the content?) making the menus load almost instantly after the first access for each parent. Each submenu was unique in terms of content so the content couldn’t have been cached in this case - could it?

Wait, is this kind of nesting OK?


In another thread I was told to use


... or is that only because I needed to get a whole array out of snippetB?

Ideally, you would combine the two snippets into one snippet, although it's not always practical, especially when dealing with complex snippets provided by someone else.

That kind of nesting will usually work, but remember that:

1) The snippets will always return a string
2) You've added the overhead of parsing the extra tag
3) Nesting can create caching issues