Partial caching and <% require %>


#1

Silverstripe Version: 3.7.3

Question:

Hi all, it seems to me that partial caching does not cache requirements. Consider the following code:

Page.ss, somewhere in HTML body:

<% cached 'cache key here' %>
    <% require javascript('themes/mytheme/javascript/test.js') %>
<% end_cached %>

test.js:

alert('TESTING');

Now if you test this in browser, you will notice that you will get an alert popup box saying ‘TESTING’. Then try to reload the same page again and it does not alert anything. This is because the JavaScript file is not included anymore, because SilverStripe caching does not store requirements - if I have understood correctly.

Does this same happen on SilverStripe 4? I haven’t tested it, but I’m asking if someone else knows.

Sorry, I’m in a little bit hurry, so I have to leave now. I will submit more information later if needed or edit this post is it’s unclear.

Thank you for your support!


#2

That makes an amount of sense to me. The cache only contains the actual content generated between the tags. The <% require %> is calling a method which adds the JS file to the assets, but that doesn’t actually make any difference to the generated content.

In reality, the requirements call needs to be outside the cache block so it it still processed by the viewer when the page is rendered.


#3

Yes, it kind of makes sense. But as template structures and includes can get complex, it’s sometimes hard to see what requirements are needed by a specific cached block. If a cached block is big and contains many includes, it’s hard to keep track of the requirements.

I’m not necessarily suggesting any modifications to the core behaviour of the partial caching mechanism. I’m rather asking if anyone knows of any possible hooks in the partial caching system that would let me to program my own “requirements collector” that would keep track of require calls in cached blocks and reapply those when content is loaded from cache.


#4

You should just be able to wrap your require tag in an <uncached> block… I can’t quite remember if that works for nested templates though. SS3 use to have some issues with that kind of thing - I recall that if $Layout was in a cache block (even if wrapped in an uncached block) things didn’t work as expected, so I always ended cache blocks at $Layout and started a new one after it. Not sure if SS4 has the same issues.


#5

Thanks, I need to try that :).