Caching has nothing to do with user sessions - it’s very granular (it caches part of resources, individual elements etc) but caching based on a user session as well destroys the point of caching.
The thing is - when someone visits a page that hasn’t been visited before, MODX decided (based on the cached/uncached tags you are using and other settings) that it caches parts of the resource to a file. That way when the next user checks out that page, you can quickly serve most content from file already saving a lot of query time to the database.
Now if it would take in to account user sessions, and write cached to file with an addition session identifier you will run into two problems:
1: you can only serve resources from cache which the user has already visited that session (which may very well be cached by the browser as well already), implying that most users will not see a file from cache at all.
2: your cache will be enormous. If 10 visitors visit 5 pages each, that would mean you have 50 unique resource caches as it takes into account the user session. Now, if you would just cache what can be cached with the cache system as it is, you’ll only have 5 (assuming the visitors visited the same pages) cache files. So that’s only 10% of the size in your cache and with the right elements uncached no difference for the user (but probably faster pageviews as more is served from cache).
So yes: it is wanted behavior. But easy to fix by calling the chunk uncached as it will then check for permissions every request, or using the personalize snippet which does that too.
BTW, you can install Personalize via the package manager and more info is here:
http://modx.com/extras/package/personalize
And nothings’ wrong with running snippets - they rock and make you able to do dynamic stuff while separating content from logic.
☆ A M B ☆
