NOTE: Using Views 7.x-3.1
Not sure what's happening here, but I have attempted to use the In Cart block view to provide a block across the store I am working to indicate the number of items the user has in their cart (a pretty normal implementation of this feature I believe).
I've added screenshots below depicting the scenario.
The Items in Cart is placed as a block at the top of the content and is available on all pages.
Prior to placing any items in the cart the block doesn't show or indicate any items in the cart.
After placing any item in the cart, the total reflected in the block doesn't change.
After removing items from the cart, the total reflected in the block doesn't change.
Emptying the cart still shows the same number of items in the cart.
I'm baffled... could this be a bug in the commerce and/or views modules?
| Comment | File | Size | Author |
|---|---|---|---|
| #10 | Region capture 10.png | 99.15 KB | timodwhit |
| #10 | view_block_header_links.txt | 62.19 KB | timodwhit |
| #5 | Testing Orders including abandoned or emptied carts | 162.4 KB | craigkendall |
| #4 | Here it is in a .txt file as well | 5.5 KB | craigkendall |
| Image showing home page after removing 1 item still shows 5 items in cart | 644.67 KB | craigkendall |
Comments
Comment #1
mr.baileysJust to rule something out: are you sure the page or block is not served from cache?
Comment #2
craigkendall commentedGreat question. I have tried clearing the cache and refreshing and no change.
I have also disabled any custom pricing and shipping rules I have set up (for tax and flat rate shipping) and the result, even clearing the cache manually is still the same.
The one thing I have thought of, but not yet tried (thought I would see if anyone had a "Oh, I had that and solved it by..." suggestion first) is creating a from-scratch Drupal Commerce Kickstart installation and seeing if the behavior is similar to rule out any of the modules, etc. I've implemented from causing the errant behavior.
Comment #3
rszrama commentedHmm, definitely a common use case, and I was under the impression it should work. In fact, a test on a clean Kickstart shows it does - there's nothing special about that area handler, really. It just tallies up the total quantity of all line items in a Views result set and prints out a number. This tells me there's a problem in your customization some where (since you've ruled out caching issues). I do appreciate the screenshot approach to documenting the problem, though. : )
Perhaps you can post an export of the View so we can check it out? Perhaps there's something about the way you've customized it that's causing it to always count 5 line items or something strange like that.
Comment #4
craigkendall commentedI was afraid you were going to say that... (part of why I had not already done the Kickstart default install to test it... hoping it was not so).
Glad to post the view export! Essentially I cloned the Shopping Cart one so I had something to work with. Then disabled the display of the main fields and used the line item summary in a footer and in order to have the styling I needed around it placed global text items with opening and closing div tags above and below the feed of the line item summary.
Thanks so much for the feedback and attempt to help.
Comment #5
craigkendall commentedHere's an interesting added piece of information.
I noticed there was a limit of 5 items on the max amount in the Pager section so I set it to 0 and discovered there were actually 20 items showing as in the cart.
It appears that even though I have emptied the cart when testing different things in the store, it appears there is some record of those carts (see attached image) and deleting each one will decrease the number of items showing in the cart.
So that prompts a question... how long will those emptied or abandoned cart records stay in the View Orders listing and is there a way to delete from the list any "ghost" listings when someone deletes all the items in their cart?
Comment #6
craigkendall commentedJust trying to bump this in case rszrama or others have not seen the added #5 or #4 info.
Comment #7
timodwhit commentedI don't know if this is relevant but it seems very similar to what is happening and I think it could be associated with the Order ID.
Here is my user case: I come to a site login add something to the cart. Decide "I don't have money for that" log-off, but keep the item in my cart. I return to the site, forget to login but add something to the cart. The item now added to the cart creates a new order ID because I am anonymous (this is what we want) but then what ends up happening is I go, "Oh man, I need to login" and when I login, the cart only has the most recent order id loaded. And ignores my previous orders and does not display them to me.
If this is correct, my guess is that we could do a couple things: 1) figure a way to combine orders (this is not a good idea, because it means that a user would not have control over which order to choose and/or there could be a possibility that the user ends up dissatisfied.) 2) I think it would be good to have the option of being able to take an order and "Add to current order". Otherwise, just keep the orders separate and show the user "Item's recently added to the cart."
Sorry if this isn't relevant. But I was struggling with the views and managing them appropriately because my cart looked so goofy.
Comment #8
timodwhit commentedDigging deeper: Looks like like the problem is coming in around line 600 of commerce_cart.module,
So in the best case scenarios they should not have more order than one but what can end up happening is that if you start as anonymous and then log-in, your previous orders are lost... This would then create the error of dups/challenges in the creation of a blocks associated with the cart.
Also, I'm not a php programmer, so I'm solely basing the above code based on the commenting.
Comment #9
rszrama commentedHmm... Realistically, most people will only have 1 cart as commented, but there are no technical problems with someone having multiples. I actually demonstrate that functionality in all our trainings and never get any errors.
Comment #10
timodwhit commentedHey Ryan,
I don't know if I would call it an error on the issue, the problem that is vexing is the aggregation of orders in views and I think there might be some interesting things happening with how views is handling the "views_form_commerce_cart_default" form.
Here is where I am getting an issue: If you notice the customer ("me") has two orders that are appearing in the cart. The header links are generated using aggregation in views and aggregation with the the filter "Commerce status = in shopping cart." The cart form is currently only pulling the most recent order ID (ex: order ID:48). So if a customer leaves an item in the cart, logs-off. Adds something anonymously, logs-on. A new order is present and only the new item is present in the cart. It makes sense why this is necessary, but the problem that I have encountered is trying to make the previous "in shopping cart" items a) no longer present in the view, b) edit-able by the customer. Allowing the customer to come back to those items that may be on the wish list.
Would there be a way to append the form to have it pull all orders/ allow customers to move items from one order to another order while the order is in certain state? Or is there a better way to do aggregation than aggregating all commerce line items?
Attached are a screen shot and my view.
Thanks for the help
Comment #11
rszrama commentedRight, I understand how to make multiple shopping carts as a single user. We've had that functionality for quite some time, but what I don't understand is why your Views are including line items from multiple orders. That technically isn't possible given the way the default Views work. I see that you've added a custom display to the Cart block View (on the to-do list for core, but needs an upgrade path), so you are also responsible for adding the argument (contextual filter they're called now) to limit the View to only use the customer's current shopping cart order. The tools are there for you to use, you just need to choose the right default value for the order ID argument.
I don't think that is the original issue here, though, right?
Comment #12
timodwhit commentedsorry for the confusion.
The contextual filters aren't quite working for me, will give it more tries. Sorry if this diverted the original issue, thought the two were related. oops.
Comment #13
craigkendall commentedContextual Filter solved my issue. THANKS! I added a contextual filter for the COMMERCE LINE ITEM: ORDER ID selected the PROVIDE DEFAULT VALUE option and set it to CURRENT USER'S CART ORDER ID. Viola!
Thanks for the pointer rszrama!
Comment #14
craigkendall commentedOh, fixed.
Comment #15
timodwhit commentedWhat great success!!!! Thank you so much, craigkendall and rszrama!
I added a pager to the links to only display the recent order, pulled in aggregation, as well, and no longer the dups of orders or the problems associated with multiple "in-shopping cart" displays. Thanks.
Comment #16
rszrama commentedExcellent, glad we got a solution. : )