storageType "Cache" Buggy?

Anyone else change the default storageType to ‘cache’ and found that the cart gets buggy? I have been going mad the fro the last few hours after switching from cookies to cache. All of a sudden cart is not always current. Sometimes it shows empty until after a reload or doesn’t reflect updates until after a reload.

Looking at the source I am think now that maybe the cache is not getting written fast enough and the page is rendering before the cache is able to be read. Although it should all be synchronous so that doesn’t quite seem right either.

Mostly posting this as an FYI to others.

*Note: It’s possible that this has to do with my local VM environment.

1 Like

Can’t say I’ve heard or seen issues with that, but then again I haven’t had the storage set to caching much! I can give it a try tomorrow/over the weekend and review the code, but just to make sure, it is working as expected for you when set to cookies or session?

Could you elaborate on your VM as you highlight that as potential issue, anything special to take into account?

I have not yet tried session but flipped back to cookies and all is fine again.

As for my VM I run an ubunutu instance which runs apache and php but the actual site root is a share folder on the host ( me dev machine OSX). I have found that cache in general does not like this setup so i have updated the filepath to the cache so that it writes to the fs within the ubuntu vm. This works fine and has so for a very long time.

There is very little to the code that writes to cache vs cookie. The biggest diff I see is that for cache the existing cache file is first removed and then rewritten so I thought maybe in my environment that is taking to long.

I just noticed this issue happening on a site I’m building, tonight. I also switched back to cookies as a work-around but wanted to mention that there does seem to be something happening here.

We just ran into a problem with storageType “Cache” as well: if one user clears his shopping cart (deletes all items), the carts of other current logged in users are cleared as well.

Is there any progress on this issue? We would really like to continue using the Cache storagetype if possible.

I think we fixed this temporarily by changing some lines in simplecartcontroller.class.php:

above each occurrence of the line:
$cacheKey = 'user_' . sha1($this->modx->user->get('id'));

we added the line:
$cacheOptions = array(xPDO::OPT_CACHE_KEY => 'simplecart/'.'user_' . sha1($this->modx->user->get('id')));

This way each user gets his own folder in core/cache/simplecart

If there’s a better way to handle this please let me know!

I just played around with storage type “cache” and can confirm the behavior Adam Smith describes.
Adding a product to cart doesn’t immediately update the cart content. Page reload is required to get an actual view.

I also think that this problem is based on the fact that the cache isn’t written in time!

Any solution/workaround for this problem?

The problem is, using storage type “cookie” limits the cart to about 35 products. The cookie simply gets too large. Browser cookie limit is 4 kb (tanks Mark for the hint).

I’ve prepared a somewhat better fix for the one-customer-clears-cart-all-carts-are-gone issue reported by @vierkantemeter. It’s included in the 2.5 release, but consists of changing

$this->modx->cacheManager->refresh(array($cacheOptions[xPDO::OPT_CACHE_KEY] => array()));

to

$this->modx->cacheManager->delete($cacheKey, $cacheOptions);

in simplecartcontroller.class.php, around line 535 (removeStorage method).

Just to make sure, the issue with the cart contents not showing up is not a parsing issue where a “mini cart” is incorrect because the cart processing happens by a later snippet call? It’s always incorrect?

If I switch storage type to “cookie” all works fine, so it can’t be a problem of snippet call timing.