Download the PHP package ttempleton/craft-nocache without Composer
On this page you can find all versions of the php package ttempleton/craft-nocache. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
Download ttempleton/craft-nocache
More information about ttempleton/craft-nocache
Files in ttempleton/craft-nocache
Package craft-nocache
Short Description A Twig extension to escape caching inside cache blocks
License MIT
Informations about the package craft-nocache
No-Cache
A Craft CMS Twig extension that escapes caching inside cache blocks
It also works when disabling the cache from included files:
template.twig:
If you need to reference variables outside of the nocache
tag, you will need to pass a context – much like how the include
tag works when passing variables. Note that you do not have to pass global variables, such as craft
or currentUser
, but you will have to import your macros again.
Requirements
No-Cache requires Craft CMS 4.0.0 or later.
Installation
No-Cache can be installed from the Craft Plugin Store or with Composer.
Craft Plugin Store
Open your project's control panel, navigate to the Plugin Store, search for No-Cache and click Install.
Composer
Open your terminal, navigate to your project's root directory and run the following command:
Then open your project's control panel, navigate to Settings → Plugins, find No-Cache and click Install.
Example: User information
Say you have a list of products you want to show on your page. Under each product, you want an "add to cart" button. However, you only want to show this button if a user is logged in. Not only that, but you also want to disable the button if the user already has it in their cart. Unfortunately you're outputting 20 products a page with images, so caching the list seems like the responsible thing to do.
Now we have a problem. The cache around the list of products will cause the currentUser
logic to essentially not work, since they'll be cached along with the products. You can't isolate the user logic by separating things into multiple cache blocks, since you're in a loop, and the whole point was to cache the database call that grabs the product entries. So you either have to apply your user checking in Javascript (far from ideal), or disregard caching altogether.
With nocache
tags you can fix this very easily:
The nocache
block will allow you to cache the entire product list, but still perform your user logic outside of the cache. It also allows passing of context, so you can still refer to products and entries inside the nocache
block and access their properties, without any additional database calls.
Example: CSRF tokens
A fantastic security feature, but one that basically renders caching impossible to use. Often you might find yourself outputting a form to the frontend, but it's nested deep within a stack of template includes and macros. At the top of this stack you've conveniently wrapped a cache tag around it.
Well, now your CSRF tokens are going to be cached and there's basically nothing you can do about it. Using nocache
tags, this is no longer a problem:
Now you can include this form anywhere in your templates and not have to worry about your CSRF tokens being cached. As a side note, yes nocache
tags will work even when they are not inside a cache block (though try and avoid doing this as nocache
tags do add some overhead).
Caveat
Content inside nocache
blocks will render slightly different than normal. Variables declared outside of the nocache
block will actually have their values cached for the duration of the cache block.
This causes an issue in situations like the following:
You would expect that if you were to change the title of the article, it will update inside the nocache
block. This is not the case, as the article itself would be cached due to the cache block.
There's a few ways around this. You could move the {% set articles %}
statement within the cache block, so updating the article would cause the cache to bust. In situations where you are using the article inside the cache (but outside the nocache
block) this is the preferred method, as you won't spend any database calls grabbing the article inside the nocache
block.
The other option is to query for the article inside the nocache
block. This can be better than the above solution as updating the article title will not bust the cache. The difference in this situation is now the contents of the nocache
block will cause a database call.
Every situation will be different, so use your best judgement.
Big thanks to Ben Fleming for creating No-Cache and for letting me take it over.