I've got Smidge creating minified CSS/JS bundles, with the CacheBuster set to "AppDomain". But the Smidge configs only seem to vary the cachebuster value based on the "Version" value, which I'm not using.
This means, despite actual cache file being updated, the filename is always style.css.v1, and so browser caching causes any changes to be ignored.
Does anyone know how to get the AppDomain cache buster to generate a unique hash, as "Version" does?
I think the idea is in production the filename is a hashed combination of assembly version, Umbraco version and the version string...
... I think you are not meant to see the version number in the URL, although the conversation suggests it might be a good idea to do so for intuitiveness.
This is in production, and I was expecting to see a dynamic hash, as the Smidge docs suggest.
The lack of a changing version number in the URL makes the cache buster useless, as browsers will cache the file based on the filename alone - they don't care what goes on behind the scenes. a request for a cached "style.css" will always return a cache hit as (by design) that happens before the file is requested from the server (to allow any Smidge invalidation to happen).
The only way around this seem to be to set the generated files to nocache, but then there's just extra processing overhead on every page load to check if the file needs to be rebuilt (when the browser caching would do that for you).
If this is a deliberate obsfucation choice by Umbraco, it seems like flawed logic to me.
Yes, you should see a hash! otherwise it won't cache bust! as you rightly say!
On that conversation that's what we found, when set to 'Version' we were expecting to see a version number on the Url, but what we were seeing instead was the hash. (this is V9)
and apparently this is the expected behaviour in 'Version' mode, the version number is just used in the generation of the hash, so manually changing the 'Version' number regenerates the hash.
Hey Neil, did you ever find a resolution for your issue? I'm also experiencing a similar issue, but for a v10 site. I'm guessing it's a bug in Smidge itself.
I trawled through the source code and it seems to be Umbraco, not Smidge that has the hard-coding - but none of the code is exposed to allow us to change it.
I've done some more digging and it appears it's something to do with not passing the configuration options to the native smidge functions - so the built in SmidgeHelper isn't using them.
I trawled the source code and found an undocumented Umbraco.Cms.Web.Common.RuntimeMinification.SmidgeRuntimeMinifier which re-implements CreateCssBundle and CreateJsBundle for the back office - if I inject this into my view and use those functions, the files are generated with the correct AppDomain cachebuster.
I've posted my findings on the GitHub issue tracker and asked for either a) The native functions to be supported, or b) the SmidgeRuntimeMinifier overloads to be documented somewhere.
Issues with Smidge minification (v11)
I've got Smidge creating minified CSS/JS bundles, with the CacheBuster set to "AppDomain". But the Smidge configs only seem to vary the cachebuster value based on the "Version" value, which I'm not using.
This means, despite actual cache file being updated, the filename is always style.css.v1, and so browser caching causes any changes to be ignored.
Does anyone know how to get the AppDomain cache buster to generate a unique hash, as "Version" does?
Hi Neil
There is a conversation here, around the time the UmbracoSmidgeConfigCacheBuster was introduced:
https://github.com/umbraco/UmbracoDocs/pull/3891
I think the idea is in production the filename is a hashed combination of assembly version, Umbraco version and the version string...
... I think you are not meant to see the version number in the URL, although the conversation suggests it might be a good idea to do so for intuitiveness.
https://docs.umbraco.com/umbraco-cms/reference/configuration/runtimeminificationsettings
Not sure if that helps, is this in development or production environment? eg Smidge does not doing anything in debug mode...
regards Marc
This is in production, and I was expecting to see a dynamic hash, as the Smidge docs suggest.
The lack of a changing version number in the URL makes the cache buster useless, as browsers will cache the file based on the filename alone - they don't care what goes on behind the scenes. a request for a cached "style.css" will always return a cache hit as (by design) that happens before the file is requested from the server (to allow any Smidge invalidation to happen).
The only way around this seem to be to set the generated files to nocache, but then there's just extra processing overhead on every page load to check if the file needs to be rebuilt (when the browser caching would do that for you).
If this is a deliberate obsfucation choice by Umbraco, it seems like flawed logic to me.
Hi Neil
Yes, you should see a hash! otherwise it won't cache bust! as you rightly say!
On that conversation that's what we found, when set to 'Version' we were expecting to see a version number on the Url, but what we were seeing instead was the hash. (this is V9)
and apparently this is the expected behaviour in 'Version' mode, the version number is just used in the generation of the hash, so manually changing the 'Version' number regenerates the hash.
The logic appears to be here https://github.com/umbraco/Umbraco-CMS/blob/33adbf41fa1f5c5d0759c70a7116114107addf56/src/Umbraco.Web.Common/RuntimeMinification/UmbracoSmidgeConfigCacheBuster.cs#L59
But I'm not sure why you are not seeing the hash (eg bug in V11, or some sort of config thing)
regards
Marc
Yeah, in "Version" mode, I just get whatever my hardcoded version value is (no hash at all.
In "AppDomain" mode - which is what we want to use, we always see "v1" (the default version string).
Most annoying.
Hey Neil, did you ever find a resolution for your issue? I'm also experiencing a similar issue, but for a v10 site. I'm guessing it's a bug in Smidge itself.
Nope, not yet I'm afraid.
I trawled through the source code and it seems to be Umbraco, not Smidge that has the hard-coding - but none of the code is exposed to allow us to change it.
I'm just holding out hope for a fix in v12.
Okie dokie, are you able to create an issue in GitHub (https://github.com/umbraco/Umbraco-CMS/issues/new/choose) with the details of what you've found so far?
It might be that they simply don't know about the problem yet, and if it's detailed in the issue tracker it can get picked up by anyone to fix :)
I've done some more digging and it appears it's something to do with not passing the configuration options to the native smidge functions - so the built in SmidgeHelper isn't using them.
I trawled the source code and found an undocumented Umbraco.Cms.Web.Common.RuntimeMinification.SmidgeRuntimeMinifier which re-implements CreateCssBundle and CreateJsBundle for the back office - if I inject this into my view and use those functions, the files are generated with the correct AppDomain cachebuster.
I've posted my findings on the GitHub issue tracker and asked for either a) The native functions to be supported, or b) the SmidgeRuntimeMinifier overloads to be documented somewhere.
In case it helps anyone while we wait for an official answer - I've posted my workaround on the Github issue I opened.
https://github.com/umbraco/Umbraco-CMS/issues/15165#issuecomment-1816661375
is working on a reply...