Here's another cache problem: Take a look at this site: http://www.krxa540.com In the upper left is a "What's on now" block. I created this by using in the block to display the correct info based on current time. But, when I turn on the cache, whatever show was on at the time the cache was turned on stays there forever. It occurs to me that individual blocks, pages should have a lifetime parameter so that they can expire as needed for things to run properly. Theoretically, that means you could set the lifetime on a particular page or block to "0" and that page or block would never get cached. Here's another possibility: How about setting a block to "Don't Cache". Then the actual code for that block would be stored in the cached page and would therefore execute when the cached page is displayed. In my KRXA example, the entire page would be cached. But, the "What's on now code" would be inserted into the cached page so it would execute when the page is displayed. I understand that this would make the caching less efficient. But, it would also allow the caching to be used and still allow some dynamic page content. Note that on the KRXA site, there's also a weather module. Caching freezes this as well. Geoff Alex Markley wrote:
Hey all!
I'm sure most of you are busy with other stuff, but I thought I'd make some noise about this issue because it represents a potentially serious design flaw in the caching system.
My original, scatter-brained report is here: http://drupal.org/node/75186
I'm not terribly familiar with the caching system as it is, and I know there are other discussions going on about improving it. Thus, I'm not interested in trying to "tell people like it is" or stepping on anybody's toes. I'm just trying to bring up an issue that I know exists and have confirmed to be a problem in 4.7.2.
Specifically, while Drupal does a really great job of caching all pages generated by anonymous requests, it does a really, really crappy job of clearing them.
Unless I'm mistaken, I don't see any maximum lifetime for cache entries, which I believe to be design flaw number one. Even if that maximum lifetime is over a month, it still protects Drupal-powered sites from serving year-old stale/invalid content to anonymous users.
Design flaw number two is that many content updates don't clear any cache entries, resulting in bad/stale content being served to anonymous users:
==> Example: At the moment, admin/node operations immediately result in stale content because they don't trigger any cache deletions.
==> Example: User profile updates immediately result in stale content because they don't trigger any cache deletions.
Design flaw number three (my favorite one) has to be the complete and utter lack of an intelligent cache clearing mechanism.
For example, why in the name of heaven does node_save do a cache_clear_all(); ?! It should be calling a hook that allows interested modules to clear cache entries that they created! That would prevent good cache entries from being deleted and ensure that old cache entries are deleted on the spot.
I guess my beef is that irresponsible modules are failing to clear cache entries when they are rendered invalid, and hacks like calling cache_clear_all(); from node_save() are short-sighted at best.
This problem is bad enough to make me seriously consider the sanity of enabling the cache on my site at all, since anonymous users are my primary audience.
Feel free to disagree.
ttyl --Alex Markley (Malex) http://MalexMedia.Net/
-- Geoff Staples Warning. Use this email system for confidential communications at your own risk. The President of the United States has issued an executive order allowing the National Security Agency to surveil domestic email, telephonic communication, U. S. Mail and all other forms of communicaton. Although no communication can be guaranteed to be secure, confidential communications made in person at an unknown location arranged via pigeon carrier, smoke signal, or commercial courier are suggested.