Who is using nocache?

[wisskid]

While rewriting Smarty for v5 I stumbled upon the various ways Smarty supports cache busting through:

• the {nocache}...{/nocache} block
• the {yourtaghere nocache} tag option available for most template functions
• the optional nocache-parameter when assigning a variable: $tpl->assign('name', 'Bob', true) or {assign var="name" value="Bob" nocache}
• cacheability of plugins

See: https://smarty-php.github.io/smarty/programmers/caching/caching-cacheable.html

These features enable you to activate output caching on your Smarty templates, but nevertheless keep certain parts dynamic. The resulting cache file is a mix of static output and dynamic PHP code.

The logic required to make this work is very complex. It slows down the caches (obviously) but it also places extra burdens on the developer implementing them. For example:

• If a tag is executed in nocache mode you must make sure that all other variables used by that tag are also assigned from PHP when the page is loaded from the cache.
• The nocache status of an assigned variable will affect the compiled template code. If you change the status you must manually delete existing compiled and cached template files to force a recompile.
• For plugins: the $cacheable status will affect the compiled template code. If you change the status you also have to delete existing compiled and cached template files.

At iWink, we've never used these features. We do have a custom {cache}...{/cache} block though, which does exactly the opposite. It allows you to cache certain parts of an otherwise dynamic template, storing the output in memcache instead of file based caches for example. By specifying a cache key, you can control when your caches will invalidate.

I am in favor of removing the nocache-functionality from Smarty and adding the {cache}...{/cache} block as a substitute for the occasions where you might benefit from caching parts of a template. But before doing so, I figured it would make sense to poll if others are depending on this.

So please answer this poll and if you using this functionality please share how and why.

[wisskid]

@AnrDaemon @glensc @uwetews @dusta @thirsch @JonisoftGermany @xorti @ssigwart @IT-Experte @Hunman @mohrt @scottchiefbaker @mreiche love to hear your thoughts on this matter

[dusta]

I don't remember ever having problems with cached results from functions. Dynamic variables I usually put in php.
However adding {cache} It seems to be something more practical then {nocache}

This can be used e.g. to save some rand() function in template.

script.js?v={cache}{some_rand_function}{/cache}

useful thing with CloudFlare

[thirsch]

I've just grepped through all of our templates and we are not using it. Also, I wasn't aware it exists. Nevertheless, it sounds good to me to have the {cache}-Tag and there are some cases this might be useful for us as well.

[Visualq]

We use a custom {cache name=xx} tag aswell. Tried to incorporate the {nocache} tag but it's much less intuitive when you're working with a lot of dynamic templates. It's much easier to {cache} the resource intensive parts.

[wisskid]

Care to compare notes on our {cache} implementations?

[Visualq]

This smarty_internal_compile_cache.php.txt is basically what we use. We compile the cache has/get/set directly into the template. It should be easy to adjust the function to store it in the compiled template folder.

[wisskid]

thanx

[ssigwart]

I use Smarty in multiple projects and don't use nocache. I actually don't use the caching feature at all because almost all my templates are dynamic.

[JonisoftGermany]

Same here. See my answer below.

[saulery]

We don't use the cache system withr WIKINDX. For other project at work I have not used the cache feature.

It is very reasonable to provide only one of the two primitives and preferably the one that is has a positive and explicit meaning. {cache}{/cache} receives my favor if I had to use it because I don't see why caching an entire template.

[scottchiefbaker]

I have never used nocache... in fact I learned that nocache was a thing when this discussion opened up.

I have no strong feelings about nocache.

[mohrt]

I’m ok to axe it. It a seldom used feature that lends to bad habits imho.

…

On Fri, Jan 27, 2023 at 5:42 PM Scott Baker ***@***.***> wrote: I have never used nocache... in fact I learned that nocache was a thing when this discussion opened up. I have no strong feelings about nocache. — Reply to this email directly, view it on GitHub <#853 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAHZCLBRAO2V4LRDXK2ZFDLWURMNHANCNFSM6AAAAAAUIUPUYU> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[W1zzardTPU]

We use Smarty caching a lot at TechPowerUp, but never with nocache, just grepped my sources. We do use clearCache() though

[JonisoftGermany]

In all projects so far, I disabled caching at all and made sure, caching lifetime is set to zero. More than 90 percent of content is dynamic. It is not suitable to disable caching at each template or loop or to set nocaching for every single assigned variable.

Because of general disabling cache, there was no need to use nocache-tag, nor nocache attribute at loops nor defining assigning variables as nocache. I would like to know if others also chose this way.

I was and am responsible for many different projects using Smarty, which have hundreds of templates. You really need to dig deep to find content, which is NOT dynamic. But who uses Smarty for static websites?

[JonisoftGermany]

SmartyML, the multilingual version of Smarty, compiles language placeholders into the template. Because this is done at compile time, caching is not used.

[mreiche]

I used Smarty for years in big projects with many templates and a lot of custom extensions. We were also using the caching feature by default, to reduce load in heavy used environments. We were only using {nocache} for dynamic areas like User profile information or other dynamic generated content, everything else was static. That made it possible for us to reduce the page rendering time to less than 40ms. {nocache} helped us, to prevent caching for whole areas, not only single tags.

This was an architectural decision, because the caching feature was kind of a USP of Smarty for us. But this feature also had a bug, which I fixed in my personal fork, because the core developer team never accepted #407 as a bug.

[wisskid]

I think Uwe was actually right not to accept this as a bug (sorry), but your example goes to show how complex the current architecture is.
When rewriting the code I noticed the strange conditional application of the output filters too. Only now I understand why it is so.

[mreiche]

I agree, that it's actually not a bug. But a useful feature request to run output filters that have been registered previously even on cacheable templates.
Anyway, I personally don't work with Smarty or PHP anymore. But I think, technically, there is no much difference between {nocache} and {tag nocache}.

I prefer writing template code like:

<navigation>
{nocache}
{user_profile var="user"}
<img src="{$user.image.url}"/>
<ul>
    {foreach $item in $user.navigation}
    <li>{$item.url}</li>
    {/foreach}
</ul>
{/nocache}
</navigation>

instead of

<navigation>
{user_profile var="user" nocache}
<img src="{$user.image.url nocache}"/>
<ul>
    {foreach $item in $user.navigation nocache}
    <li>{$item.url}</li>
    {/foreach}
</ul>
</navigation>

(Pseudo code may be not correct)

[AnrDaemon]

This is, after all, a question of "what to cache". Do we cache source data or a compiled template output?

[mreiche]

Both. I used to load source data dynamically like:

{user_profile var="user"}
Hello {$user.name}, your last login was {$user.last_login_date|relative_date}.

Which will be cached by default (when caching is enabled) and performs a huge performance gain by prevent loading any data (no sessions is initialized, not database connection is established).

Hello Mike, your last login was 2 days ago.

But using {nocache} prevents caching of these high dynamic areas:

{nocache}
{user_profile var="user"}
Hello {$user.name}, your last login was {$user.last_login_date|relative_date}
{/nocache}

[IT-Experte]

I use nocache only one time.

{nocache}{if $smarty.server.REQUEST_URI eq '/'}<script>var xxx=123;</script>{/if}{/nocache}

I think I can change to a attribute nocache.

{if $smarty.server.REQUEST_URI eq '/' nocache}<script>var xxx=123;</script>{/if}

[wisskid]

I was hoping to remove the attribute nocache as well 😀

But I'm sure you can implement this with {cache} blocks as well.

[doekenorg]

The {cache} option would need configuration to be able to choose a backing implementation; like redis, memcache, filesystem, custom; dare I say memory.

[Visualq]

I agree, and probably it should be defined on the Smarty object, expecting a PSR-16 interface. By default let it use the filesystem.

[doekenorg]

Might even be a key on the tag itself to specifically switch that implementation. E.g. {cache backend='redis'}.

Those configurations would need to be named, so we can have multiple backends with the same type.

[AnrDaemon]

Why would template knows anything about infrastructure? Simply flat out "no". Don't do that mistake.

[doekenorg]

It wouldn't directly. But configuring multiple caches like shortterm and longterm can be used simultaneously without it knowing about the underlaying infrastructure.

[AnrDaemon]

You can make your caching infrastructure react to special names of cache identifiers, but that's about it. From template perspective, there's no cache, just data to render.

[AnrDaemon]

Bad habits or not, the caching feature was one of the primary reasons for Smarty to exist.
It is indeed a less important feature in modern world, where dynamic pages are built using JavaScript, but for many legacy applications switching to an opposite behavioral model may not be as intuitive as it sounds in theory.
One of my projects using nocache flags/tags in places, where content has to be different for each session (ex. shopping cart), while the rest of the page remain static (and is VERY resource intensive to build).
If a middle ground has to be struck, I would suggest placing nocache logic at the obvious edge: make it a function of template composition. Your entire insertion is either cached or not, but there's no fragments of a single page that behave differently from the rest. Then you could merge cached parts directly into a single compiled presentation and use active code to attach dynamic content.
Tracking variables that needs to be initialized for dynamic pages to behave is a problem of the user, not library author. If you deliberately making parts of your template dynamic, it's your call, we just provide an option.

TL;DR: Remove {nocache} blocks/block flags, retain cache control for included templates/plugins.

[wisskid]

Thank you for your input. Suppose we have a template base.tpl that includes header.tpl, body.tpl and footer.tpl. In this example header.tpl contains a non-cacheable part. Wouldn't it be easier to simple mark body.tpl and footer.tpl as cacheable, and treat the rest as dynamic?

[AnrDaemon]

I would just say that header.tpl has to be included as code (i.e. refer to compiled template rather than try to make a cached version of it) regardless of caching abilities of the environment.
Caching, after all, is a function of code, not data.
Unless I'm seriously mistaken, it's easier to provide a "do-nothing" stub function (in case, "caching" module that does no caching) than to switch between different implementations.
I think that was actually a reason to ship "caching" as default feature, even if it has to be manually enabled to actually do anything useful.

[deadowl]

I have it in some code, but it's vestigial at this point because browser form autocompletion made loading from cookies/session data obsolete.

[marclaporte]

For the record, the Tiki project uses Smarty since 2002 (https://doc.tiki.org/Smarty-Templates) but doesn't use nocache.

[kythuatwebso]

Why not have {cache} abc {/cache} .
I thinks this best.
Do not need to cache all and except with {nocache}

[AnrDaemon]

#853 (reply in thread)