I have lots of views which don't change very often, and enjoy the benefit of caching. But I have 1 view which is used to display a random quote in a block in my sidebar, which I do not want cached. Is there a way to disable caching for this particular view? Specifically, I want to see a different quote every time I refresh the page.
UPDATE: I have Caching Mode set to Normal in my site's Performance settings, and I've tried going into the View and setting Caching = None (as well as in Block settings: Caching = Do not cache), and going into the Views tools page, and selecting "Disable views data caching", and it works when I'm logged in, but as soon as I logout, the quote stays the same after refreshing.
UPDATE: I'm beginning to think that if you have enabled page caching in Drupal, then all other cache settings are ignored (i.e. View and Block caching). Can anyone confirm this?
In the Views UI under the Basic settings of a particular display you have an option called Caching make that as none. And your view won't be cached. So you get random
quote everytime. :)
EDIT : Oops how did I miss what you were telling :(
Use Cache Exclude module to disable caching on the particular page. If your random block is on many pages, you may need to dig deeper to find an alternate solutions. All the best ;)
Suggestion: Randomize on the client side. Load 'em all up into a javascript array and write a quick function to select the random quote on page load. Unless there are hundreds of possible quotes it shouldn't weigh the page down too much, & you could exclude this one little sidebar feature from consideration when working on your caching strategy.
In fact even if there are hundreds of random quotes, you could use a combination of the two approaches. Grab 50 random lines w/ your module and them let javascript pick from there. To an end user it would be nearly identical.
The block may be being cached. Did you try to http://drupal.org/project/blockcache_alter ?
You can also directly change a block's cache setting in the database with something like:
update blocks set cache=-1 where bid=<blockbid>;
Setting this cache entry to -1 means the block will not be cached.
In addition, setting cache to 1 will cache the block per role, 2 will cache the block per user, 4 will cache the block per page, and 8 will cache the block exactly once (the same for all users, pages, etc).
Related
I want to cache page but the problem is that the button connect is
also cached because it's in the layout. Is there a way to exclude layout page from cache and .net core will generate only the layout again and the inner page from cache without cachetag
[ResponseCache(CacheProfileName = "Default")]
No. Response caching is literally caching the response, i.e. the entire HTML document. There is no concept of what is layout, a partial, etc. It's just an HTML document. You can use the cache/distributed-cache tag helper to cache portions of the view, but you cannot cache the entire response, if you only want to cache some portion (i.e. exclude the layout itself).
That said, you can certainly vary the cache on a particular header, whether a user is logged in or not, etc. So, depending on why you're wanting to not cache the layout, it might be possible to actually cache the whole response, including layout, and yet still present different versions.
I have an ascx control which works just fine. It is contained in a larger aspx page. I want to put it in the fragment cache, so I added the appropriate CacheOutput directive at the top. However, now the control on the underlying aspx.cs file has the control variable set to null the second time the page has loaded. I found a few places on the web where it said this would happen, but I also didn't find a solution to accessing the control.
What am I missing?
Also, can I control where it is cached? Can I make it cache in the browser cache rather than at the server?
Question #1: Output caching only stores the HTML result on the server. If you want to interact or run any code in the user control at all, you may not use full output caching. You may want to look into a lower-level caching, perhaps database or object caching, or embed another user control within this one that uses full output caching itself but the outer user control no longer does.
Question #2: "Can I control where it is cached?" If you use output caching, then no. That always means cache on the server. However, there are lots of different levels of caching. You can only cache a full HTTP response at the browser: a single HTML page, a CSS file, etc. If you want to cache only part of a page at the browser, but have the rest of the page dynamic, you would have to do it with some kind of JavaScript. Either HTML5 local storage, or via AJAX that has appropriate caching headers or responds with a 304 Not Modified response.
Side note: The term "fragment cache" is more often referred to "partial caching" in the ASP.Net world.
SO Tips: These are two questions, and should really be asked as two individual questions in the future.
Also, there are many ways to solve your problems here; if you provided more context to what you are doing and the performance problem you are trying to solve, we could offer more specific answers.
our drupal site has some user specific content. When we enable page caching the whole page is being cached. Isn't it possible to cache only fragments of the page. Or specify which fragments not to cache? Or even specify which pages not to cache. This way we can remove some stuff from the caches when logged in. Or don't use the cached versions when logged in.
I found this website already but it doesn't seem to work:
http://www.jpstacey.info/blog/2009/03/03/how-to-not-cache-a-particular-drupal-page
But this doesn't seem to work.
kind regards,
Daan
First, I second Ran Bar-Ziks suggestion of putting the 'not to be cached' data in a separate block and set that block to BLOCK_NO_CACHE, as it is the simplest solution.
If that is not possible, you can disable caching of specific pages, but contrary to the suggestion from the link you posted, I'd do this by preventing the page from getting cached in the first place (rather than removing the cache entry afterwards).
To do this, you can manipulate the global cache config setting temporarily on the page in question:
// Disable caching for this request cycle
$GLOBALS['conf']['cache'] = FALSE;
Where you put this code depends on the pages you want to exclude from caching:
If it is a custom node type coming from your own module, you'd put it in hook_view.
If you want to do this for a node type coming from other modules, you can put it in 'view' operation part on a hook_nodeapi() implementation.
** This would also also work for individual nodes, if you add a check for the node id before disabling the cache.
If you need to do this based on paths, you could put it in a hook_init() implementation, checking for the path (or path alias) to decide whether to disable caching or not.
It should be obvious that you need to clear caches first for any of these approaches to work, as they depend on preventing the page from being cached at all. They will not remove an already paged entry from the cache.
You can put the data that you don't want to be cached in block and use BLOCK_NO_CACHE to prevent this block from caching. It is very simple thing to do and explained in drupal.api: http://api.drupal.org/api/drupal/modules--block--block.module/constant/BLOCK_NO_CACHE/6
Yes! Drupal caches the menu by default, for example. That's usually on every page.
See the cache getters and setters (below). You can make your own by setting a unique cache ID.
http://api.drupal.org/api/drupal/includes--cache.inc/function/cache_get
http://api.drupal.org/api/drupal/includes--cache.inc/function/cache_set
The task is relatively straightforward:
A Drupal website displays a list of articles with thumbnails. Some visitors would like to view it without images by clicking on a button/link and have that preference saved.
e.g. http://patterntap.com/collections/index/
The problem is all visitors are anonymous and given certain traffic, page cache is enabled.
My idea was to use some simple JavaScript to set a cookie, refresh the page and depending on the cookie values (or its presence/absence) display or hide the images.
Except Drupal serves cached pages quite early and the only quick way to modify the cached version that I could find is by hacking includes/bootstrap.inc and add a custom class to the body classes then hide the images with css.
A very wrong approach, I know. But I wonder if there is a way to save different versions of a page and serve the correct version?
Edit:
need to keep the same uri
the js to show/hide the images without reload and set the cookie is already in place
hook_boot() is not really called for cached pages, so can't do it via custom module
.htaccess mods?
Edit/solution:
In the end went with Rimian's suggestion. But it is possible to accomplish the task using our own cache.inc implementation as seen in the Mobile Tools module. Specifically, by extending cache.inc and updating settings.php to include
$conf['page_cache_fastpath'] = FALSE;
$conf['cache_inc'] = 'path/to/my/module/my_module_cache.inc';
So let me get this right. You wanna hide some images on a cached page if the user chooses to?
Why don't you write some jQuery or javascript and load that into your cached page with all the rest of the document?
Then, the client/browser would decide to run your script and hide images depending on some parameters you passed along with the request to that page or in the cookie? The script gets cached and only runs when you call it.
If you were hacking the bootstrap for something like that you'd really need to be rethinking what you were doing. Crazy! :)
Also take a look at cache_get and cache_set:
http://api.drupal.org/api/drupal/includes--cache.inc/6
I'm not sure I 100% understand what you are trying to do but here are my thoughts. One of your root problems is that you are trying to access what is essentially different content at the same uri.
If this is truly what you want to do, then Rimian's suggestion of checking out chache_get and chache_set may be worthwhile.
Personally, it seems cleaner to me to have your "with thumbnails" and "without thumbnails" be accessed via different uri's. Depending on exactly what you are wanting to accomplish, a GET variable my be an even better way to go. With either of these two options you would hide or show your thumbnails at the theme layer. Pages with different paths or get variables would get cached separately.
If you want the visitor to be able to switch views without a page reload, then jQuery and a cookie would probably suite your needs. This wouldn't require a page reload and switching back and forth would be quite simple.
What is the most standard or best way to persist data between requests?
Should I use cookies or session variables? I'm interested in keeping data like sort order, sort column, and page number (for paginiation).
I'm coming from a webforms background so normally this type of thing was automatically handled for me in the viewstate of the controls I was using.
update
I like the querystring idea, for searching and more meaningful URLs; however, I'm working on an "index/list" view, which consists of a View with header, and "control" options, like DDLs for filtering and a partial view that renders the table of data.
The DDLs use a $.load() to call an ActionResult on the controller, which returns the partial view, passing parameters there in the querystring, but since these are ajax requests the main page url of the user's browser does not get updated.
Is there a best-practice for taking querystrings off the main-page URL and using them in ajax requests to other ActionResults?
If you want it to survive only through one request/redirect TempData is your friend.
However, for things like your pagination, URL is the best method, for the ability to share links alone.
A standard way is to pass those sort of things via URL Query Parameters. You can modify your routing to expect certain URL variables. That way the pages become more search engine friendly as well.
It depends on how permanent you want the information to be:
Things like the page number should indeed be in the URL (as others have pointed out) - this helps with bookmarking, etc, but remember that if you add more content to the list, then that bookmarked result set will not always be what the user wanted...
If you're happy for these values to be lost when a session times out (by default around 20 minutes), then put them in Session.
If you think that sessions are going to timeout before the next request, or you want to save it across visits then you should be storing them in either cookies, or a profile (potentially allowing "Anonymous" profiles, which work with the users cookies, so they would lose them across machines).
Personally, I'd think very carefully about putting sort order and columns in the URL if you do you could actually end up really confusing search engines:
Lots of pages with very similar content (page 1, sorted by date desc, page 1 sorted by date asc, etc) - search engines don't like duplicate content, and nor should you as Google (for instance) will only show two pages from your site in a default result set, you want them to be valid, not duplicates.
Search engines will spend lots more time crawling your site, and potentially give up - If on every page they find links to "Sort by this column", they will attempt to follow them, resulting in more work on the server, higher bandwidth use, etc.
These can be mitigated through the use of a Robots.txt file denying access to sorted versions of the page, but if this is generated almost dynamically that will be very complex to maintain going forward.
In response to your update, a nice way to achieve that for pages would be to have links to "Previous" and "Next" pages of results (or better yet, a list of all pages in the list), output on the page, with the page numbers, that you then hide with JavaScript.
This way users should see your nice, AJAXy behaviour, and search engines (and users without JavaScript - mobile, or those using older screen readers for instance) will still be able to get access to all your pages - this will help your pages to degrade gracefully, or use "Progressive Enhancement".
Things that were previously in viewstate should probably be put back in the clients hands via either hidden fields or cookies.
Session is "too" easy. In a dev environment it works great, pretty much no matter what you put in it. In production scalability and persistence become a problem. In-process session is likely to disappear unexpectedly if you have crashing bug in your site, and requires server affinity when load balancing. Out-of process session fixes the durability and affinity issues, but can still be a performance bottle neck if too much stuff is put in session. A VERY common problem is that each page will put 1 or 2 items into session but never take them out again when they are done. And even if a page removes it session data when it is no longer needed, the data can still get orphaned if a user starts a process and never completes it.
Cookies is a fast and simple way to persist data between requests, and you can also make them live only for a limited time depending on your needs.
Session are easiest.