I use macrocaching quite a lot and for some of them I have set quite a long expirytime on the frontpage of my site, because I don't need to refresh the contents often. It seems that all macro caching is removed (also the ones with long expirytime on the frontpage) when a node is published. Is this correct ? and if so how do I prevent the macros being refreshed on publish? I would prefer the macros to expire when the expirytime is reached and instead refresh the macros manually if I need to update the contents before the expiry time is reached.
I'm not aware exactly how it works in details, but as for me this behaviour seems to be absolutely correct. In general caching means that you get content from a slow storage and put it to a fast storage so that reuse it without going anytime to the slow one. As the slow storage gets updated you want to have a fresh version of content in the fast storage.
I don't know how to turn off the behaviour your mentioned, but probably something like a warm-up process after publishing could be of help. I.e. requesting pages by some robot to get the cache filled up again as soon as possible.
In my case it expires macros which does not have anything to do with the published page. I totally agree that expiring macros which relate to the published page makes sense.
In umbraco.presentation.macro.cs line 510 a macro is cached with the key "macroHtml_" and if I look at the umbraco source in umbraco.presentation.content.cs, line 146 it says:
@Thomas, I think it'd be quite hard to expire only macro's relating to the published pages. For example, a page might be referred to in a user control macro, and the CMS has no way of looking in the user control to see if a page is being referenced by it. You could maybe do it with the XSLT ones, but it'd still be quite hard (and relatively slow) to parse through them all checking for references. Bear in mind that there are also multiple ways of referring to a page, e.g. by ID, by DocType, as a descentdent/ancestor in an XSLT select, all of which would have to be checked for!
Macrocache expires on publish
I use macrocaching quite a lot and for some of them I have set quite a long expirytime on the frontpage of my site, because I don't need to refresh the contents often. It seems that all macro caching is removed (also the ones with long expirytime on the frontpage) when a node is published. Is this correct ? and if so how do I prevent the macros being refreshed on publish? I would prefer the macros to expire when the expirytime is reached and instead refresh the macros manually if I need to update the contents before the expiry time is reached.
thanks
Thomas
I'm not aware exactly how it works in details, but as for me this behaviour seems to be absolutely correct. In general caching means that you get content from a slow storage and put it to a fast storage so that reuse it without going anytime to the slow one. As the slow storage gets updated you want to have a fresh version of content in the fast storage.
I don't know how to turn off the behaviour your mentioned, but probably something like a warm-up process after publishing could be of help. I.e. requesting pages by some robot to get the cache filled up again as soon as possible.
I sort of agree :-)
In my case it expires macros which does not have anything to do with the published page. I totally agree that expiring macros which relate to the published page makes sense.
/Thomas
BTW, I've just quickly skimmed over the code and I haven't managed to find at once the place pointing to clearing the macro cache on publishing.
At least you could try one of the following:
Hi Rodion
In umbraco.presentation.macro.cs line 510 a macro is cached with the key "macroHtml_" and if I look at the umbraco source in umbraco.presentation.content.cs, line 146 it says:
Cache.ClearCacheByKeySearch("macroHtml_");
@Thomas, I think it'd be quite hard to expire only macro's relating to the published pages. For example, a page might be referred to in a user control macro, and the CMS has no way of looking in the user control to see if a page is being referenced by it. You could maybe do it with the XSLT ones, but it'd still be quite hard (and relatively slow) to parse through them all checking for references. Bear in mind that there are also multiple ways of referring to a page, e.g. by ID, by DocType, as a descentdent/ancestor in an XSLT select, all of which would have to be checked for!
:)
@Tim, thanks. It kinda makes sense :-)
I am trying to use standard .net outputcaching on my user controls. Do you know how I can vary the caching by page?
thanks
Thomas
is working on a reply...