Excessive use of cache_clear_all()

I've only vaguely looked into what you are doing currently, but I imagine that in order for cache_clear_all() to solve this problem, you would effectively have to turn off the cache for the entire site. Except caching wouldn't actually be turned off; you'd just be building and then clearing it all the time, which would make performance worse than if it was turned off completely.

As I understand it hook_init() is not called for cached pages. I guess the Cache Exclude module gets away with it because it always operates on the same few pages and so those pages never get cached. With our shopping cart, the situation is different since we want to show the updated cart on every page.

I was going to suggest checking the session in hook_boot() and disabling caching if there are items in the cart for that session. Unfortunately, hook_boot() is called a fraction too late. There's a recent issue about this: #322104: Allow hook_boot() to disable page cache

You can't just do a cache_clear_all from within hook_boot either, because then other anonymous users will start seeing the wrong cart details. So the redirect you suggested doesn't make sense.

So, unless I'm missing something (quite likely), these are the possible solutions I can think of:

1. First of all make sure there is an option to fix this in Drupal 7 (see issue linked above for starters).

2. Create some kind of temporary user account. (I have no idea how that would actually work, but thought I'd put it out there!)

3. Bring the cart data in through an AJAX request. (I'm pretty sure this will work, but haven't thought it through properly yet.)

4. Disable the dynamic part of the cart block for anonymous users.

5. Manually get people to add the check to the $conf array in settings.php. Perhaps make that a progressive enhancement for one of the above options (might work well with 4).

Might be worth seeing how our e-commerce friends do this too.

What a pain. :)

I've taken a look at e-commerce and they have gone with option 4.

I believe this is serious enough to warrant a critical priority.

The short answer is no, there isn't.

The way that Cache Exclude works is by never allowing a cache to be built for certain pages. The flow goes like this:

- anonymous user requests a page
- bootstrap asks if caching is enabled. It is.
- bootstrap looks for the cached entry. None has been set yet so it returns null
- because there is no cached entry for this page, the page gets rebuilt
- hook_init gets called by Cache Exclude module. Depending on the URL, page caching is set to FALSE.
- drupal_page_footer() is called. It asks if caching is enabled. It is not, so the cache does not get set again for this page.

In other words, it relies on the cache never being set for certain pages.

But with Ubercart we want the cache to be set for most anonymous users; just not those who have something in their cart. The only way you could make this same method work is if you cripple caching for all pages. This would be better than what you are currently doing, but it does still mean you've effectively disabled page caching for all users of ubercart. Site owners would be better off not turning on page caching at all in the admin interface.

What would be preferable is when you display the cart, check if the user is anonymous and also if caching is enabled, and if so just show a link to the cart. Then if the user turns off page caching, the full cart will be displayed. Turn it on and they just get the link.

Not ideal, but much better than what you've got currently and the site owner is in control.

Then you could could put some instructions in the readme file telling them how to have their cake and eat it too, by conditionally setting $conf['cache'] = FALSE in settings.php. This is the only place you can currently disable loading the cache conditionally; since the earliest hook occurs after the cache is already built.

I'm not sure if the AJAX idea would work or not, but it would build on the above in any case.

No, those will get cached also. The only exception is when not using GET for a request (i.e. a form submission) or if there is a message in drupal_set_message(). Using the cache exclude method may be the right answer for /cart/* if you never want them cached.

Can't you just set the block in question to not cache, like the core user module does for the login block? I have done this in modules before, where I didn't want info like username to be cached in a block - here's the actual user module code from user_block():

function user_block($op = 'list', $delta = 0, $edit = array()) {
  global $user;

  if ($op == 'list') {
    $blocks[0]['info'] = t('User login');
    // Not worth caching.
    $blocks[0]['cache'] = BLOCK_NO_CACHE;
    ........
  return $blocks;
  }
  ........
}

If you can tell me what to check for, I can test it now - I am actually officially testing out Ubercart at work for the next day or so... =)

Ok - just porting the UC Worldpay module to D6 this afternoon, but I'll test this tomorrow and report back. =)

"Can't you just set the block in question to not cache"

That's fine for block level caching, but won't help if you have page caching on.

Really? It seems pretty pointless as an option then, since nearly everyone uses page caching on "production" sites. Are you sure about that?

Edit: I think you're wrong. The manual does not describe this, and other options for blocks include BLOCK_CACHE_PER_PAGE - it would be a nonsense for such an option to exist if block-level caching was not smart enough to affect the page cache.

Block caching is most beneficial for authenticated users, who don't ever see a full page cache.

The manual is stating that the block does not get cached in the block cache. But it still gets cached as part of the overall page cache.

I don't see why BLOCK_CACHE_PER_PAGE would be nonsense. That simply allows a block to look different depending on the page being viewed. The page cache would cache whatever the block outputted for that individual page. Then you'd go to another page, the block would output something different and that difference would be cached.

The manual is stating that the block does not get cached in the block cache.

No it isn't... *you* are. The manual makes no such reference. The string "block cache" is simply not there. You're assuming. I'm not saying you're definitely wrong, because without reviewing the block module's code I can't know, but it is not my interpretation of the documentation...

Then you'd go to another page, the block would output something different and that difference would be cached.

Which would, *by definition*, mean it's not in the page cache, or that behaviour wouldn't work! :-/

Oh, I see what you mean - I'm not convinced. Maybe I have too much faith in the block module. ;-)

We need to check the code of block.module to confirm/deny this. I will do so when I check the behaviour of the module, as the success or otherwise of the approach will prove/disprove theories on how the block module works! All will be revealed...

After further investigation I have to tell you alpritt is right (thanks for jumping in and saving a load of time).

It seems page cache for anonymous users has no awareness of block cache settings whatsoever. In short, it is absolutely impossible to serve a dynamic block to anonymous users with page caching enabled on a Drupal site. It fundamentally will not work. =(

This AJAX cart claims to bypass the cache:
http://www.ubercart.org/contrib/6148

Yes, AJAX seems to be the only solution I could find too. Shame. =(

Whichever way you look at it, "resolving" the issue with cache_clear_all() is not the answer, as effective you're switching off page caching for everyone without asking them, and in an expensive way (Drupal build cache, Drupal clear cache, Drupal build cache, Drupal clear cache, etc!)

It would be better, for now, to recommend page caching is left OFF if you intend to expose the cart block to anonymous users and recommend the contributed Ajax Cart module as an alternative if you want to run page cache AND expose the cart block.

Interesting discussion (subscribing).

FYI, this patch has just gone in for Drupal 7. I've not looked at it closely but it appears to stop pages being cached for anonymous users when there is something stored in $_SESSION, which will solve this problem. Something to look forward to... #201122: Drupal should support disabling anonymous sessions

Hope we can resolve this by "Block Cache Alter Module". http://drupal.org/project/blockcache_alter