Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Anonymous checkout is enabled but cart block always shows: "View your shopping cart."
Comment | File | Size | Author |
---|---|---|---|
#67 | 377798-ubercart-uc_cart-lazy-session-creation-67.patch | 2.13 KB | neilnz |
#64 | 377798-ubercart-uc_cart-lazy-session-creation.patch | 1.73 KB | neclimdul |
#51 | uc_cart_no_session_for_anonymous_pressflow_users.patch | 1.21 KB | mkalkbrenner |
#47 | uc_cart_pressflow_caching.patch | 756 bytes | mkalkbrenner |
#16 | uc_cart.module.patch | 551 bytes | emilymoi |
Comments
Comment #1
ARray CreditAttribution: ARray commentedI've reverted uc_cart to 6.x-2.0-beta3 and it works now.
Comment #2
rszrama CreditAttribution: rszrama commentedThis is intentional. It does this for anonymous users when caching is turned on to prevent caching cart blocks w/ items in them that would be displayed incorrectly to other anonymous users. See http://www.ubercart.org/docs/user/9168/cart_block_now_safe_page_caching.
Comment #3
Erik Seifert CreditAttribution: Erik Seifert commentedThat's quiet bad. This changes make it really hard for me to implement my features. Because to make this work in UC BETA4 i must copy much code from uc_cart_block. I this is not the correct intention for drupal way. I will contact discuss this in ubercart forum.
Comment #4
Erik Seifert CreditAttribution: Erik Seifert commentedSolutions:
(1) Turn cache off
(2) Override theme_uc_cart_block_content_cachable and return theme_uc_cart_block_content
For the first time ;- )
Comment #5
Erik Seifert CreditAttribution: Erik Seifert commentedComment #6
rszrama CreditAttribution: rszrama commentedYour #2 will work just fine.
Comment #7
ARray CreditAttribution: ARray commentedSorry for stupid question, but how to:
Override theme_uc_cart_block_content_cachable and return theme_uc_cart_block_content?
First function has no params, but second has them.
I'd written in my template.php:
[code]
function {MYTHEME}_uc_cart_block_content_cachable()
{
return theme_uc_cart_block_content();
}
[/code]
And it gave me an error.
Comment #8
rszrama CreditAttribution: rszrama commentedGood point... I guess you'd really have to copy/paste the code from the hook_block() function that generates those variables in the first place.
Comment #9
Erik Seifert CreditAttribution: Erik Seifert commentedYeahh this is really a problem. I tell this the lead developer from ubercart, but they wont change this now.
Comment #10
jide CreditAttribution: jide commentedI had the same issue, and using the cacheexclude module helped me disable the cache for the particular pages where the cart is present.
Hope this helps !
Comment #11
kirannsai-1 CreditAttribution: kirannsai-1 commentedI am an novice user can you give me more details on how to use the option 2?
>>(2) Override theme_uc_cart_block_content_cachable and return theme_uc_cart_block_content
Option 1 is not feasible for me due to performance issues
Comment #12
jide CreditAttribution: jide commentedUse cache exclude module on cart pages.
Comment #13
Kirannsai-2 CreditAttribution: Kirannsai-2 commentedThis still doesn't work for me, I use the cart in a block and it never refeshes even after using the cacheexclude module. I have also tried disabling the cache blocks options.
do i miss anything?
Also given the performance issue with disabling these, is there any other option we can use?
Comment #14
Duplika CreditAttribution: Duplika commentedSame here and I'm using the latest dev version and tried disabling block cache with no luck.
Comment #15
emilymoi CreditAttribution: emilymoi commentedIf solution #2 is possible, why doesn't it happen by default? Why is it more desirable to have an empty cart shown? Obviously no one is going to use an empty cart block... Seems like a bad design decision to me.
Comment #16
emilymoi CreditAttribution: emilymoi commentedThe reason disabling block cache doesn't work is because the uc_cart.module explicitly looks to see if cache is enabled globally when it decides to show an empty cart.
I don't see why it can't just check to see if the block cache is enabled here.
I have attached a patch against 6.x-2.0-beta5 that works great for me.
Comment #17
seaneffel CreditAttribution: seaneffel commented@bfcam, your patch works. Patching the uc_cart.module file this way ensures that the block is invisible to anonymous users when block caching is turned off. At the very least, this patch should be committed.
@ubercart, this is just bad design. Block caching is a site wide performance feature and asking admins to switch off this feature in order to hide a block is madness. When users check the "Hide block if cart is empty" option then they should get what they expect.
Comment #18
emilymoi CreditAttribution: emilymoi commentedComment #19
rszrama CreditAttribution: rszrama commentedSo, in the words of Andre the Giant, "I do not think it means you think it means."
I need some clarification, and it looks there are confused issues here. This issue started out as a request to have a dynamic cart block for all users, anonymous or authenticated, whether caching was turned off or on for a site. This has traditionally resulted in "ghost" carts for anonymous users, where a page gets cached with a cart block that has items in it and future anonymous users see the cached version before they ever add items to the cart.
All that said, I investigated block caching and found it to be insufficient for what we needed to avoid that error. If cart blocks aren't being hidden properly when empty (I don't recall testing this, so it's quite likely), that's a separate issue and will require its own patch in a separate issue in the tracker here. I don't see how the patch in #16 will affect that.
Comment #20
emilymoi CreditAttribution: emilymoi commentedCan we please have a test case that demonstrates why turning off block-caching is not sufficient to prevent ghosting for anonymous users?
I tested the scenario on my site and could not reproduce the problem.
Thanks.
Comment #21
rszrama CreditAttribution: rszrama commentedDid you also have normal page caching turned on at the time? When I looked into the workflow during bootstrap, an entire cached page of HTML was being delivered up before block caching was ever even considered. It bypasses the majority of the page building process. What is cached is the entire HTML result of a rendered page, which doesn't care whether block level caching is on or not.
So, to put it another way... Page not cached yet? -> Content rendered and block caching delivers cached blocks (instead of rendering them afresh) -> All the resulting HTML cached for the next anonymous visitor.
That's my understanding, but I think I mentioned before, this isn't something I've investigated recently. The last time I had a serious look at is was when I made the change in the way the block worked, probably two months ago now.
Comment #22
seaneffel CreditAttribution: seaneffel commentedI have a test case, a second site I've been working has the same problem. http://www.squarefour.org.
If one of you wants to look on the admin end, and can give me time to back up before I let you in, I can give you access.
Comment #23
asak CreditAttribution: asak commentedsubscribing.
I'm playing with this, and it seems like there should be some more thought put into this issue.
I'll return with my conclusions & 2 cents in a bit ;)
Comment #24
seaneffel CreditAttribution: seaneffel commentedMaybe we should branch this issue into two separate ones.
One issue for the cart block that shows items in the cart that were not selected by the anonymous users.
Another issue for whether the "hide block when cart is empty" feature is designed the best way and if it is functioning correctly.
That might draw clarity to this thread.
Comment #25
mkalkbrennersubscribing
Comment #26
Vacilando CreditAttribution: Vacilando commentedSame problem as originally reported, in UC 2.0 rc1... It really is a problem because normal caching has to be on on any sane site but showing 'View your shopping cart' on sites that have a shop but also plenty of other non-commercial sections is rather ugly.
I've ended up not showing the block for anonymous users rather than pushing it in their face even when they are not after shopping and even though the cart is empty anyway.
Comment #27
escoles CreditAttribution: escoles commented[Subscribing.]
This also raises an admin UI issue.
Here's what it says currently on the Performance page:
[emphasis added.]
This thread seems to make it clear that it's not just "aggressive" caching, at least with regard to uc_cart.
I think some of the negative reaction to this may be due to some of us finding this to be unexpected behavior. We see the admonition not to use the shopping cart and the store with aggressive caching; that makes sense. So we take what we think is a safe, conservative strategy of using normal mode caching and if we don't do a fairly extensive regression test after turning on the cache (and so catch the fact that the cart block doesn't behave as expected), we risk getting nastygrams from our users (or worse, our clients) about unexpected block behavior.
Comment #28
rszrama CreditAttribution: rszrama commentedYeah, there's alternate work going on in the Drupalsphere to fix that message about aggressive caching. Not a lot of modules have to deal with normal caching issues, so Ubercart is something of an exception. All I can say is this has been discussed in various places and announced/hashed out on Ubercart.org, and I'll be sure that it's in the 2.x user's guide. Getting a 2.0 compatible UC AJAX Cart module going will solve this issue for 95% of people I imagine.
Comment #29
InTheLyonsDen CreditAttribution: InTheLyonsDen commentedsubscribing
Comment #30
asak CreditAttribution: asak commentedBut... thre is a UC Ajax Cart going... what must be done there to fix this issue?
It seems like it's the solution...
Has anyone had any success with Ajax Cart displaying products in cart for Anonymous users?
Comment #31
PeteS CreditAttribution: PeteS commentedI concur that the default output of theme_uc_cart_block_content_cachable is kind of confusing since everyone is going to assume that checking "Hide block if cart is empty." will cause an empty block to be hidden in all situations, no matter what the intentions are with caching. I just implemented the theme function to return a blank string, and all is good.
Comment #32
j0rd CreditAttribution: j0rd commentedI think we should have the ability to disable caching for this particular block. I don't think disabling caching for the entire site is something people would want to do. I will try solution #2 in post #4...but I'm not sure if this re-causes the bad cache issue, which we're trying to fix.
Ideally, we should have some way of easily disabling the cache for uc_cart_block and in my opinion this cache should be turned off by default (even if site caching is turned on).
I'm using UBERCART--2-RC3
EDIT: I've managed to get it working by modifying some things in my themes template.php, but there's no way an ubercart end user which minimal experience will be able to figure this out easily. I believe you'll get more complaints about this until an easy solution for end users is provided.
Comment #33
rszrama CreditAttribution: rszrama commentedI think I've explained this before, but again the problem is that "block caching" doesn't refer to cached pages per se. In other words, you could disable the block cache for the cart block, but the real problem is that pages were being cached that contained full cart blocks, and these were being displayed to users who hadn't put anything in their carts (and vice versa). Check the bootstrap functions... page caching circumvents any other page generation, including block caching.
Comment #34
Vacilando CreditAttribution: Vacilando commentedrszrama is right.. this thread is a dead lane. Look at his post #28 -- what we need to achieve this functionality is UC AJAX Cart module... see http://drupal.org/project/uc_ajax_cart
Comment #35
j0rd CreditAttribution: j0rd commentedSo to confirm. Post #4, Solution #2 if implemented, will or will not encounter cache issues?
Is that a temporary fix to resolve this issue?
Please excuse my ignorance, but debugging the cache system of drupal is a bit outside my realm of knowledge.
Comment #36
rszrama CreditAttribution: rszrama commentedIt will encounter cache issues. It just goes back to functioning w/ ghost carts like UC 1.x did. As #34 linked to, the solution is a dynamically loading cart contents section for anonymous users.
Comment #37
j0rd CreditAttribution: j0rd commentedThanks for the clarification. I'll take a look at uc_ajax_cart and see if it can resolve my issue.
Comment #38
robomalo CreditAttribution: robomalo commentedUc_ajax_cart didn't solve the problem for me. I had to turn off caching for the site which sucks. I can't use cache exclude for only cart pages, b/c I need visitors to see their cart on every page but only when something is in the cart. I have spent a lot of time on this and it is utterly broken.
Comment #39
seaneffel CreditAttribution: seaneffel commentedCould you at least get the patch from #16 above into a release so we don't have to patch it with each incremental dev version? The patch above has been tested to solve a portion of this problem:
http://drupal.org/node/377798#comment-1479264
Thanks!
Comment #40
seaneffel CreditAttribution: seaneffel commentedComment #41
rszrama CreditAttribution: rszrama commentedI've discussed that patch in comment #19, and my other comments in this issue get at the real fix. These were never answered satisfactorily. I'm checking the global cache on purpose, unless something has changed in Drupal 6 since the time of this code to change the behavior of the global vs. block cache.
Comment #42
hanoiiJust wondering around ubercart and cache and also noticed this. So the real thing is that there can't be any shopping cart block if cache is enabled, am I right?
I will try out the ajax cart sometime soon, but I am not sure if will fit my purpose. I is there any alternate solution? Overriding the cachable theme function would fix this? I would think not otherwise it should have been used like that in the first place.
And I wonder if the explanation in http://www.ubercart.org/docs/user/9168/cart_block_now_safe_page_caching is accurate?
If I understood correctly, the cart block is not 'safe' with page caching, it simply outputs an empty cart block even if the cart is not empty. I think this should be explained in that page at least to give some clarifications and options for users who search for this kind of information.
I am sure a lot of thoughts have been put into this, just wondering if my conclusions are right or there's something I am missing :s?
a.=
Comment #43
rszrama CreditAttribution: rszrama commentedThat help page is correct in that it's "safe" meaning the same content will be cached for all anonymous users. The reason it wasn't "safe" before is that cached pages were being displayed to customer who had not added products to their cart showing that they had the wrong items in their cart. The point as described on the page isn't it always works the same regardless of whether caching is on or not but that it reverts to a version that is safe for caching if caching is on.
fwiw, I do think some sort of AJAX solution in core is the ideal way forward.
Comment #44
mr.andrey CreditAttribution: mr.andrey commentedsubscribing
Comment #45
ronenb75 CreditAttribution: ronenb75 commentedsubscribing
Comment #46
aegnor CreditAttribution: aegnor commentedfile:/includes/bootstrap.inc line:1040
------------------------------------------
case DRUPAL_BOOTSTRAP_LATE_PAGE_CACHE:
// Initialize configuration variables, using values from settings.php if available.
$conf = variable_init(isset($conf) ? $conf : array());
$cache_mode = variable_get('cache', CACHE_DISABLED);
+ if($_SESSION['uc_cart_id']) {
+ $cache_mode = CACHE_DISABLED;
+ }
// Get the page from the cache.
$cache = $cache_mode == CACHE_DISABLED ? '' : page_get_cache();
Comment #47
mkalkbrennerAs already mentioned in this thread page caching and dynamic cart block for anonymous users are incompatible by design. The only solution will be an ajax driven cart block if java script is allowed.
But there's a different approach which uses Pressflow's lazy session initialization feature (which will be part of drupal 7 I think).
Using this feature drupal doesn't start a session for anonymous users until it's really required. For example putting something into the cart starts a session for an anonymous user. The trick is that cached pages (with an empty cart) are served to anonymous users only until their session starts. I think that this trade-off regarding performance and dynamics is acceptable and might be the future solution for drupal 7.
Right now you can achieve the same applying the small patch attached to ubercart. Alternatively you can download an already patched ubercart version from http://drupal.cocomore.com/de/project/ubercart
Additionally you have to replace your drupal 6 installation with Pressflow or Cocomore Drupal Core which includes Pressflow and some additional improvements and pending bug fixes from the drupal issue queue .
Comment #48
aegnor CreditAttribution: aegnor commentedComment #49
TR CreditAttribution: TR commentedThe issue of anonymous sessions is being addressed in Drupal core. See http://drupal.org/node/590614 for a summary of where the issue currently stands.
mkalkbrenner's patch in #47 is interesting, but it only works for Drupal 7 because of the use of http://api.drupal.org/api/function/drupal_page_is_cacheable/7
aegnor's patches in #46 and #48 are impractical as they require modifying settings.php, and moreover require testing for the presence of a module-specific variable. That's not going to happen in Drupal core, and is a short-term hack at best.
I'm moving this to the Ubercart 7.x-3.x issue queue because the real fix requires Drupal core changes that are only available in D7.
Comment #50
jpstrikesback CreditAttribution: jpstrikesback commented@mkalkbrenner - Thanks! Your patch does allow the block to work again with Pressflow in use...tho it doesn't use lazy sessions, as the cart block initiates sessions all by itself (when checking for cart contents it currently calls uc_cart_get_id() which sets a session cookie if it's not already there) which of course sends my pressflow site back to the slow lane...(no per session caching here)
I kinda think the fix for this is that uc_cart_get_contents should return NULL if there is no cart id instead of creating one...does that sound about right? since everything else (adding, deleting, updating, this, that) set's cart id (and session)? I don't think the following breaks anything, but let me know if you see issues, what I've done is this:
JP
Comment #51
mkalkbrenner@jpstrikesback #50:
You're right. Thanks for pointing this out!
I created a patch based on your idea but respects the current api like returning an emty array instead of NULL.
An already patched version of ubercart including this patch and the one from #47 is available at http://drupal.cocomore.com/de/ubercart-622-cocomore-3
Comment #52
jpstrikesback CreditAttribution: jpstrikesback commented@mkalkbrenner Good call! Thanks for rolling that!
Comment #53
madhums CreditAttribution: madhums commentedi am a newbie , I don't know whether Ubercart provides variables/functions for getting "number of items in the cart" or the "total amount"... or any other variables... if we can get that, we can override theme_uc_cart_block_content_cachable() function by using these and solve the problem...
Comment #54
TR CreditAttribution: TR commentedComment #55
abhay1986 CreditAttribution: abhay1986 commented@mkalkbrenner & @jpstrikesback
making $cachable = drupal_flush_all_caches(); // works for me , is it same as disabling cache?
can you highlight something on the above code , like,
if()
{
$cachable = drupal_flush_all_caches();
}
else
{
$cachable = !$user->uid && variable_get('cache', CACHE_DISABLED) != CACHE_DISABLED;
}
Comment #56
mkalkbrennerNo you don't disable the cache but clear the cache every time. Not a good idea ...
If you like to disable the cache to get the cart to work simply turn off page caching in the administration back end.
Comment #57
abhay1986 CreditAttribution: abhay1986 commented@mkalkbrenner
I tried your patch but did not work for me as the function drupal_page_is_cacheable() is not recognized in drupal 6.x . so for me to make cart block viewable u suggest to disable the cache instead of using drupal_flush_all_caches() ? I was just concerned about performance by disabling cache from start.
Comment #58
mkalkbrennerYes, this function doesn't exist in Drupal. It's an improvement introduced by Pressflow. See my post #47:
Comment #59
Island Usurper CreditAttribution: Island Usurper commentedThere are a dozen thousand things going on in this issue.
The only one I think is actually actionable, at least for me, is lazy session loading. However, I'm not sure that it'll actually work well. From the patch in #51, it looks like you're not getting the cart id unless it already exists. I just don't see how you know it exists unless you go look for it. That sounds like the cart block always needs to load the session to see if it has anything to display, or it will never display anything to anonymous users.
3.x ought to work well enough now for someone to test this.
Despite all this, the real solution is some kind of AJAX-based cart block that gets around ALL of these issues.
Comment #60
mkalkbrennerPutting something into the card starts the session and creates the cart id.
No. It doesn't load any session data for anonymous users because there is no session. As soon as the session starts (because you add something to the cart) every anonymous user gets his individual not cached cart block (and pages aren't served from page cache any longer).
Comment #61
TR CreditAttribution: TR commentedIt sounds like this issue is closely related to #679422: hook_exit() causes Ubercart "Add to Cart" to fail, so you might want to look in there and try out that solution.
Comment #62
arnebrasseur CreditAttribution: arnebrasseur commentedI'm having this issue with 6.x-2.2. As a workaround I changed line 406 of uc_cart.module to:
Comment #63
itp CreditAttribution: itp commentedSolution in post #62 results in phantom items in the cart. My shopping cart tells me they are there, but when I view cart, they are not there.
Comment #64
neclimdulI'm not really a big fan of #51 but the idea is fairly sound. In
uc_cart_get_contents()
and for that matteruc_cart_get_total_qty()
without a passed cid, if there isn't already a cart, we don't care and can immediately return the empty case without creating the SESSION variable. I've taken a slightly different approach in my patch that just tellsuc_cart_get_id()
not to create a id if one doesn't exist. More functionality without more functions.I've also gone ahead and extended the use to
uc_cart_get_total_qty()
since there's no reason not to(and I use it in my theme so it scratches my itch).PS - Caveat, the patch was made against 6.x-2.2 not 7.x-3.x or 6.x-2.x. Apologies if it doesn't apply to HEAD.
PPS - Should we split this into actionable topic issues that don't have tons of random unrelated discussion?
Comment #65
neilnz CreditAttribution: neilnz commentedTested patch from #64 on 6.x-2.x-dev with Pressflow 6 and indeed fixed the problem of anonymous users being given a session before they add anything to their cart. For the D7 version of Ubercart this will be critical, as lazy sessions are in core for D7.
It also didn't break anything, as I was able to add an item to the cart and check it out without any problems. The session was (correctly) created at the point where I added a first product to my cart.
Another issue is that when the cart becomes empty (either after checkout completes or because they removed items from their cart), Ubercart doesn't unset the uc_cart_id session var, so the session remains when it could potentially be thrown away at that point. I've addressed this in a hook_init() of a custom module:
I'm not sure whether this has any implications, so I'll test it a bit before submitting it as a patch, but it seems to have the desired effect of the session being deleted by Pressflow once they finish checkout (and their cart becomes empty again). It seems the cart ID isn't even stored in the DB anywhere except uc_cart_products, which obviously has no matching rows for an empty cart anyway.
Comment #66
Island Usurper CreditAttribution: Island Usurper commentedneilnz, if your tests work out, I think it would be a good thing to add to this patch. It might even work better to add the unset() when the cart becomes empty than doing it during hook_init().
If it doesn't actually matter, then we can go ahead and commit it. I prefer forward porting, so I'm bumping the version number back.
Comment #67
neilnz CreditAttribution: neilnz commented@Island Usurper, Thanks. I agree that it definitely shouldn't be a hook_init()!
I've rolled it into the original patch, adding it to uc_cart_get_contents(), as this seems to be called with a rebuild action when the cart empties (either because of a completed order, or removing the last item from the cart). It can therefore unset the session cart ID when it notices the cart go empty.
New version of the patch attached.
Comment #68
neclimdulLooks like a pretty solid addition. Works as advertised (very clever fix too. much better than the init check).
Think this is RTBC from my stand point.
Comment #69
Island Usurper CreditAttribution: Island Usurper commentedOK, it doesn't look like it has any adverse effects on stock Drupal either, so I think I can commit it. Thanks for everyone's efforts in getting this figured out.
Comment #70
Island Usurper CreditAttribution: Island Usurper commentedAnd the patch worked as-is for 7.x-3.x, so committed that as well.
Comment #71
neclimdulCheers!
Comment #72
torgosPizzaEDIT: I just tested the latest dev, and it still has no effect to fix my issue, seeing as how I'm not using a Cart Block. Lyle, if you can, please take a look at that other issue here: #679422-49: hook_exit() causes Ubercart "Add to Cart" to fail
Comment #73
Island Usurper CreditAttribution: Island Usurper commentedIt's looking like torgosPizza's issue has more to do with Boost than with Ubercart, so if you're still having problems, take a look in that issue.
Comment #74
torgosPizzaYeah, Boost and any other module that invokes hook_exit() or does something else similar to abort scripts (in this case, the POST from a form).
Comment #76
wojtha CreditAttribution: wojtha commentedThis patch results in serious issues for anonymous users after upgrade to UC2.3: see #858816: Unsetting cart session causes cart contents to be lost and #862348: Cart emptied on login ... complete rework of the $_SESSION unsetting thing is needed.
(thx to @fenstrat for finding this thread)
Comment #77
alexku CreditAttribution: alexku commentedAfter upgrading to UC2.3 anonymous users couldn't add products to cart on my website. Revert to UC2.3 fixed the problem.
Comment #78
wojtha CreditAttribution: wojtha commented@alexku check #858816: Unsetting cart session causes cart contents to be lost. There is the place where we are solving that.
Comment #79
seaneffel CreditAttribution: seaneffel commentedThere are a lot of issues in here and I noticed that one of them was not addressed in the most recent update to the UC package. It seems that there are a lot of issues going on in this thread so, the issue that the empty shopping cart always displays to anonymous users has been pulled out to a separate thread to discuss there.
Feel free to disagree, but there is a patch that will bandage this problem for most people until UC can get the greater cart issues worked out.
Comment #80
garbo CreditAttribution: garbo commentedIs it correct that this problem is not occuring when the AJAX_shopping_cart module is being used? (http://drupal.org/project/uc_ajax_cart) I'm testing the dev version of that module now and it seems that anonymous users see the correct contents of their shoppingcarts in the ajax cart block.
Does anybody else have experience with this?
Comment #81
torgosPizzaCorrect. uc_ajax_cart is a different project and was created to address issues such as this one.
Comment #82
garbo CreditAttribution: garbo commentedThanks for you reply torgosPizza. I have installed and tested the ajax cart and it works like a charm! I can recommend it to others who need functioning shoppingcart blocks for anonymous users.
Comment #83
hanoiiLet me ask a question, I know there are many issues described here and I somehow thought this fix would allow us to use page cache and have the cart block work properly, but is that still not possible?
I understand the idea of using a custom AJAX solution or maybe trying out http://drupal.org/project/uc_ajax_cart, is that the only way?
What I am experiencing is the following:
Say I browsed to a product category with the cart empty, then I browse to a product and add it to the cart, the cart block is displayed properly there, then I browse back to the previous category browsing, I again see the cached version of the cart block (which is empty).
So there's no other way around this? Maybe worth documenting this on the project page? or somewhere else?
Also, have you tried the ajax cart module? What were your experiences with it?
Comment #84
torgosPizza#83, If you are using block caching, and the cart block is showing you phantom items (or showing you a cached version of the block) then yes, you need an ajax block solution.
Comment #85
hanoii@torgosPizza: Not specifically block caching, but I am using page caching which in the ends, I guess it's the same, isn't it?
Comment #86
torgosPizzaI think so, though I could be wrong. I think the main issue was with anonymous users, an ajax block gets called after the page is rendered, which means each user should be unaffected by whatever caching you have enabled.
Comment #87
garbo CreditAttribution: garbo commentedI think the problem lies in the way the cart is tied to the user: With logged in users, the cart is tied to a user ID and can therefor be pulled from the database with each pageload. With anonymous users the cartcontents are stored in a cookie (if I'm correct). And this gives trouble with loading the cart on pageload.
But as stated above: when using the Ajax cart module you can serve anonymous users with a fully functioning cart without problems! It's even better themable then the regular cart!
Comment #88
chazz CreditAttribution: chazz commentedSolution #62 works fine so far
Comment #89
MustangGB CreditAttribution: MustangGB commentedSubscribing
Comment #90
ioanmar CreditAttribution: ioanmar commentedsubscribing
Comment #91
FilipWitkowski CreditAttribution: FilipWitkowski commentedSolution in post #62 worked for me in ubercart 2. It also worked in UC Pictured Cart Block Module in uc_pic_cart_block.module file, line # 509.