I have a detail page that takes a query-string argument called CID and uses that CID to get a record from a SQL database. The sitecore/site/cacheHtml attribute is set to true. We want to keep caching enabled for the other pages in the site, but after I load this detail page once, it does not matter what CID I send to it, it always loads the first one that was sent. If I clear the cache using sitecore/admin/cache.aspx, it will load a new page. But, then that new page is cached.

I am using Sitecore 7.5 right now. We will be upgrading to 8.1 in a month or so.

This question has been asked here: https://stackoverflow.com/questions/6263747/disable-sitecores-html-cache-for-one-item

But, this group gets a lot more traffic and I thought it would be useful to ask here.


Rather than disable the HTML cache for that page, why not use the Vary by Query String option on your query-string-dependent renderings? I wrote an article that should help get you started, but the below should cover the basic overview of what you would be doing.

The 'Vary by' Cache Options

Sitecore includes support for varying HTML Cached copies of a rendering and/or rendering instance by numerous parameters, including the current value of the request query string. You can find these options in the "Caching" settings field section, along with the Cacheable option that tells Sitecore that it should cache your rendering, in the first place. Note that like the Cacheable checkbox, you can specify these options either on the rendering item itself (applies globally) or on a specific control in Presentation Details (applies only for that instance).

enter image description here

Checking one or more of these options on a rendering that you have specified as "Cacheable" tells Sitecore that it should modify the rendering or rendering instance's (depending on whether you set it on the rendering item or on the control in the presentation details, respectively) cache key based on the options that you selected. This allows you to cache renderings with varied display based on datasource, query string, user authentication state, etc.

The following table lists and describes all of the OOTB 'Vary by' options that are available to you:

enter image description here

The 'Vary by Query String' Option

One of the options that you have available to you is the Vary by Query String option. This option will cache a separate copy of the rendering for each unique combination (order doesn't matter) of query string parameters (keys and values) that are supplied in the request.

For example, if I set an instance of RenderingA on page http://domain.com/mypage to be Cacheable and to Vary by Query String then the following will hold true:

   Request: http://domain.com/mypage?hello=world
      + added copy of RenderingA to cache
   Request: http://domain.com/mypage
      + added copy of RenderingA to cache
   Request: http://domain.com/mypage?hello=foo
      + added copy of RenderingA to cache
   Request: http://domain.com/mypage?bar=baz
      + added copy of RenderingA to cache
   Request: http://domain.com/mypage?bar=baz&hello=world
      + added copy of RenderingA to cache
   Request: http://domain.com/mypage?hello=world&bar=baz
      = read RenderingA from cache
   Request: http://domain.com/mypage
      = read RenderingA from cache
   Request: http://domain.com/mypage?hello=world
      = read RenderingA from cache

Which Renderings to Set 'Vary by' Options for

Try not to abuse these options too much, in that you should avoid using them in situations where they aren't relevant. You don't want to cache more copies of your renderings than you need, or else that defeats the purpose. In the case of varying your caching by query string, just like with front-end files and browser caching even a meaningless extra query string parameter will cause an extra copy of the rendering to be cached.

You shouldn't be setting your 'Vary by' options for all renderings but rather just the rendering(s) that your options apply to. For example, if you are caching your header and your header is the same on every page but the display of Rendering A changes based on the query string parameters then you should just be using your 'Vary by Query String' option on Rendering A. Since the header never changes, there is no point in caching multiple copies of it.

In your case, if you only have one rendering that changes its output based on the query-string, then that should be the only rendering that you set Vary by Query String for, if you want to have the most optimal performance.

Where to set Your 'Vary by' Options

You can set your 'Vary by' options on either the rendering item itself or in the presentation details of the specific page item. The difference is that setting the 'Vary by' options on the rendering item will set the cache key for all instances of that rendering to vary by your settings (in this case the query string). In contrast, setting your 'Vary by' options on the control in the presentation details of the specific page item will set it only for that one instance of the control and will not affect any other instances of that control.

In case you are having trouble to find where these options can be set in Presentation Details, the following screenshot may be able to help:

enter image description here

More information:

  • Blog post I wrote for getting started with HTML Caching
  • Another blog post on the subject that I used as a reference when writing my post and which helped me get started with HTML Caching too
  • This is not working. Is the setting in my config file for sitecore/site/cacheHtml = true overriding everything? – ADH Dec 8 '16 at 21:53
  • No, that setting just enables HTML Caching for the site. Checking that setting allows you to use HTML Caching, it doesn't override options in Sitecore, but rather is required for any of them to work – Zachary Kniebel Dec 8 '16 at 22:04
  • 1
    This is working now. The problem was the controller rendering was inheriting the cache setting from another controller rendering. – ADH Dec 17 '16 at 22:13

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.