we have some sites running Umbraco9, where we have a few templates that are updated by outside developers. We are hooking up to an FTP and downloading their templates (.cshtml), and in backend their editors can choose from these templates to be inserted in a partial.
var setting = JsonConvert.DeserializeObject<CustomTemplateSettings>(Model.Value); // Getting the settings
thetemplate = setting.templateName;// Getting the selected template
showContent = _service.TemplateExists(thetemplate, forcereload);// Checking the selected template exists (physically), possibly downloading it to server
thetemplate = "/Views/CustomViews/" + thetemplate; // creating the path to the template
//Calling template - with some data
<partial name="#thetemplate" model="Model as ContentStructureField" />
Everything is great.... until they want to update their templates. Umbraco has them cached, and I need to either recycle App or hit save on a random Document Type in settings.
I have tried different things, like using #Html.Partial, #Html.CachedPartialAsync, using the tag. I cannot find a way to affect the lifespan or refresh the content of the partial
All googling results in explanations on how to cache specific content. And most Umbraco 9 specific documentation seems to have been lost with the emerging of version 10/11
I need some way to refresh the cache like when saving Document Templates. I do not care about the momentary effect on website performance, as the updates can be planned by the external developers to be non-peak hours.
Thanks in advance
Cannot figure out how to delete the question....
Turned out, that I had constructed the path to the template with a double slash ("/Views/CustomViews//TemplateName.cshtml")
While rendering engine did manage to handle this error and show the content apparently the cache did then not properly subscribe to changes to the file and kept the cached version, requiring a complete flush. Fixing the error in the path made the issue go away.
I am working with a Kentico site and I have a problem with page output caching.
We have a custom webpart which loads the records from a Bizform's record data and displays those data in a page. The problem is that after giving it several tries, we couldn't figure out the problem why the webpart couldn't get the latest data from the bizfrom data and we suspect it was because of output caching.
We tried to:
Disable webpart output caching in webpart configuration
Disable page output caching in CMSDesk > General > Output Caching
Disable site output caching in Settings > System > Performance
Disable IIS cache for both User-mode and Kernel cache
Create cache dependencies for cms.form|byid| touched key (which I found is not supported in current kentico version)
And going to try create event handler to add touched key on bizform insert event
We encounter a similar problem with Shopping Cart Mini Preview Webpart with Ecommerce.CurrentContext.CurrentShoppingCart which returns different result for service handler (.ashx - gets updated) and for webpart (.ascx - does not get updated)
If you ever experienced these problems, please help.
The last place where it could be cached is the content cache. It can be set either in Settings->System->Performance or at the web part level under System settings section.
Only web parts that utilize the content caching have this section available. (E.g. some repeaters and data source web parts.) It might be a little bit confusing because then there are two sections (System settings and Performance) where you can influence caching. However the Performance section is used to set up the Partial output cache.
Anyway, you should definitely try to check Cache debug to see what is actually cached.
Additional resources:
Deep dive – Kentico CMS Caching
New in 5.5: Caching API changes
Deep dive: Cache dependencies
Kentico caching and cache dependencies explained
ASP.NET Caching Dependencies
I have faced issue similar to second one (with Shopping Cart Mini Preview Webpart) recently. Only web service (.asmx) was used instead of HTTP handler. In my case issue was solved by setting the EnableSession property of WebMethod attribute to true for all the CRUD webservice methods.
[System.Web.Services.WebMethod(EnableSession = true)]
So I think the matter is that handler should be able to access current Session.
In case of HTTP handler you could try to add IRequiresSessionState on the handler declaration to attach it with the session.
I am also using Kentico 8, I see that your Kentico version is older. That might also have impact but I am not sure about that.
It's very important for the website I'm working on to be offline-functional. I'm using a Cache Manifest to store all the files on the application cache, so that takes care of that and all is good and well.
BUT, as I read and noticed myself, the browser first shows the cached version of the site before checking for an update online. Hitting refresh reloads the cache again, with the new cached files this time (or what it had time to update for the swift refreshers).
I'm aware of this fix : http://www.html5rocks.com/en/tutorials/appcache/beginner/, where the user is told an update is available and is asked to refresh the page. Not a bad method, but still sketchy for user experience.
Is there any other way to force the browser to show the most up to date files if online? Would cache busting all files manually AND using a cache manifest fix this problem, or will it conflict with the cache manifest and cause problem to the offline functionality?
I found something that works well for me:
The URL linking to the web page contains a parameter. If there is ever a change to the page or related files, the url is changed to something like this: http:/ /www.mywebsite.com/mypage.html?v=3 where v=3 is changed depending on updates.
This is a longer fix to implement (finding every page affected by a change & changing all their cache busting links), but the pages at least show what they're supposed to on the first load and the cache manifest still load the update for offline viewing.
I am currently working with the umbraco cms. I notice in the web.config references to session state.
My site will be on a web farm without a state server. Is umbraco reliant on session state? And if so, is it needed for content authoring or is it needed for content serving?
The front end doesn't use any session variables at all unless you code it to do so, so that should be OK for the content serving side of things.
I'm not 100% on the back office, but I THINK it's all done with cookies, rather than sessions. The easiest way to check would be to disable sessions in the web.config file and try and use the back office. If it works, you're OK, otherwise it does need the session to work for content editing.
If I understand correctly, a broswer caches images, JS files, etc. based on the file name. So there's a danger that if one such file is updated (on the server), the browser will use the cached copy instead.
A workaround for this problem is to rename all files (as part of the build), such that the file name includes an MD5 hash of it's contents, e.g.
foo.js -> foo_AS577688BC87654.js
me.png -> me_32126A88BC3456BB.png
However, in addition to renaming the files themselves, all references to these files must be changed. For exmaple a tag such as <img src="me.png"/> should be changed to <img src="me_32126A88BC3456BB.png"/>.
Obviously this can get pretty complicated, particularly when you consider that references to these files may be dynamically created within server-side code.
Of course, one solution is to completely disable caching on the browser (and any caches between the server and the browser) using HTTP headers. However, having no caching will create it's own set of problems.
Is there a better solution?
Thanks,
Don
The best solution seems to be to version filenames by appending the last-modified time.
You can do it this way: add a rewrite rule to your Apache configuration, like so:
RewriteRule ^(.+)\.(.+)\.(js|css|jpg|png|gif)$ $1.$3
This will redirect any "versioned" URL to the "normal" one. The idea is to keep your filenames the same, but to benefit from cache. The solution to append a parameter to the URL will not be optimal with some proxies that don't cache URLs with parameters.
Then, instead of writing:
<img src="image.png" />
Just call a PHP function:
<img src="<?php versionFile('image.png'); ?>" />
With versionFile() looking like this:
function versionFile($file){
$path = pathinfo($file);
$ver = '.'.filemtime($_SERVER['DOCUMENT_ROOT'].$file).'.';
echo $path['dirname'].'/'.str_replace('.', $ver, $path['basename']);
}
And that's it! The browser will ask for image.123456789.png, Apache will redirect this to image.png, so you will benefit from cache in all cases and won't have any out-of-date issue, while not having to bother with filename versioning.
You can see a detailed explanation of this technique here: http://particletree.com/notebook/automatically-version-your-css-and-javascript-files/
Why not just add a querystring "version" number and update the version each time?
foo.js -> foo.js?version=5
There still is a bit of work during the build to update the version numbers but filenames don't need to change.
Renaming your resources is the way to go, although we use a build number and embed that in to the file name instead of an MD5 hash
foo.js -> foo.123.js
as it means that all your resources can be renamed in a deterministic fashion and resolved at runtime.
We then use custom controls to generate links to resources at on page load based upon the build number which is stored in an app setting.
We followed a similar pattern to PJP, using Rails and Nginx.
We wanted user avatar images to be browser cached, but on an avatar's change we needed the cache to be invalidated ASAP.
We added a method to the avatar model to append a timestamp to the file name:
return "/images/#{sourcedir}/#{user.login}-#{self.updated_at.to_s(:flat_string)}.png"
In all places in the code where avatars were used, we referenced this method rather than an URL. In the Nginx configuration, we added this rewrite:
rewrite "^/images/avatars/(.+)-[\d]{12}.png" /images/avatars/$1.png;
rewrite "^/images/small-avatars/(.+)-[\d]{12}.png" /images/small-avatars/$1.png;
This meant if a file changed, its URL in the HTML changed, so the user's browser made a new request for the file. When the request reached Nginx, it got rewritten to the simple name of the file.
I would suggest using caching by ETags in this situation, see http://en.wikipedia.org/wiki/HTTP_ETag. You can then use the hash as the etag. A request will still be submitted for each resource, but the browser will only download items that have changed since last download.
Read up on your web server / platform docs on how to use etags properly, most decent platforms have built-in support.
Most modern browsers check the if-modified-since header whenever a cacheable resource is in a HTTP request. However, not all browsers support the if-modified-since header.
There are three ways to "force" the browser to load a cached resource.
Option 1 Create a query string with a version#. src="script.js?ver=21". The downside is many proxy servers wont cache a resource with query strings. It also requires site-wide updating for changes.
Option 2 Create a naming system for your files src="script083010.js". However the downside to option 1 is that this as well requires site-wide updates whenever a file changes.
Option 3 Perhaps the most elegant solution, simply set up the caching headers: last-modified and expires in your server. The main downside to this is users may have to recache resources because they expired yet never changed. Additionally, the last-modified header does not work well when content is being served from multiple servers.
Here a few resources to check out: Yahoo Google AskApache.com
This is really only an issue if your web server sets a far-future "Expires" header (setting something like ExpiresDefault "access plus 10 years" in your Apache config). Otherwise, a browser will make a conditional GET, based on the modified time and/or the Etag. You can verify what is happening on your site by using a web proxy or an extension like Firebug (on the Net panel). Your question doesn't mention how your web server is configured, and what headers it is sending with static files.
If you're not setting a far-future Expires header, there's nothing special you need to do. Your web server will usually handle conditional GETs for static files based on last modified time just fine. If you are setting a far-future Expires header then yes, you need to add some sort of version to the file name like your question and the other answers have mentioned already.
I have also been thinking about this for a site I support where it would be a big job to change all references. I have two ideas:
1.
Set distant cache expiry headers and apply the changes you suggest for the most commonly downloaded files. For other files set the headers so they expire after a very short time - eg. 10 minutes. Then if you have a 10 minute downtime when updating the application, caches will be refreshed by the time users go to the site. General site navigation should be improved as the files will only need downloading every 10 minutes not every click.
2.
Each time a new version of the application is deployed to a different context that contains the version number. eg. www.site.com/app_2_6_0/ I'm not really sure about this as users bookmarks would be broken on each update.
I believe that a combination of solutions works best:
Setting cache expiry dates for each type of resource (image, page, etc) appropreatly for that resource, for example:
Your static "About", "Contact" etc pages probably arn't going to change more than a few time a year, so you could easily put a cache time of a month on these pages.
Images used in these pages could have eternal cache times, as you are more likey to replace an image then to change one.
Avatar images might have an expiry time of a day.
Some resources need modified dates in their names. For example avatars, generated images, and the like.
Some things should never be caches, new pages, user content etc. In these cases you should cache on the server, but never on the client side.
In the end you need to carfully consider each type of resource to determine what cache time to instruct the browser to use, and always be conservitive if you are unsure. You can increase the time later, but it's much more pain to uncache something.
You might want to check out the approach taken by the grails "uiperformance" plugin, which you can find here. It does a lot of the things you mention, but automates them (set expiry time to a long time, then increments version numbers when files change).
So if you're using grails, you get this stuff for free. If you are not - maybe you can borrow the techniques employed.
Also - borrowed form the ui-performance page, - read the following 14 rules.
ETags seemingly provide a solution for this...
As per http://httpd.apache.org/docs/2.0/mod/core.html#fileetag, we can set the browser to generate ETags on file-size (instead of time/inode/etc). This generation should be constant across multiple server deployments.
Just enable it in (/etc/apache2/apache2.conf)
FileETag Size
& you should be good!
That way, you can simply reference your images as <img src='/path/to/foo.png' /> and still use all the goodness of HTTP caching.