Where has basket data gone?

I'm trying to access the temporary basket data, but I can't seem to find it anywhere. I'd expect it to be in the customers_basket table, but it remains empty no matter what I add to my cart (I'm assuming that's an obsolete table). I've also tried a session dump, but there's nothing there. I've even checked query logs.

Where's the data go?

Thanks in advance for any help you can give. I'm using version 1.5.4

Are you logged in as a customer?

JohnH:

I'm trying to access the temporary basket data, but I can't seem to find it anywhere. I'd expect it to be in the customers_basket table, but it remains empty no matter what I add to my cart (I'm assuming that's an obsolete table). I've also tried a session dump, but there's nothing there. I've even checked query logs.

Where's the data go?

Thanks in advance for any help you can give. I'm using version 1.5.4

No, the customers_basket table is not obsolete, but it doesn't hold the data that you think it does anyway.

As I/we have no idea what you are actually trying to do, or which part of the process you are trying to do it, it is difficult to tell you where to find what it is you are seeking.

One place to start is $_SESSION['cart']
Something like this should work

$products = $_SESSION['cart']->get_products(); 
         if(is_array($products)) { 
                   foreach ($products as $item) { 
 Do stuff 
 }
}

However, depending on where you are in the code, and what you are trying to achieve, the
$_SESSION['order_summary'] may be more suitable, and if the order has been completed you'll need to read the data from the orders_x tables.

I'm pretty sure that there are even other array variables in various pieces of the code that will also be holding the data you need. - The code snippet above, for example is using a somewhat arbitrary named variable called $products that can be 'reused' without having to repopulate it via the $_SESSION['cart']->get_products();

So, although the question appear quite simple, the answers are many and varied.

This should be enough to get you on you way though.

Cheers
RodG

And for further info, the customer_basket table holds the data of a customer that has logged in, but then logged out (either by choice or session timeout) with items in their cart... Remember, login can be either by direct choice or by beginning the purchase process.

RodG, you're right, I should have explained what I was trying to do, but thought I'd take it one step at a time. I didn't expect I wouldn't be able to find the data.

Basically, one of the products we sell is custom made. It needs to be made to exact measurements (it's sold by the foot) and has optional features that need to be viewed. I'm just getting started with ZC, but it seems like this particular product is beyond ZC's normal scope. My plan was to develop a wizard app outside of ZC that helps the customer build the product. Once finished, it dumps the product into the ZC cart with the custom specifications.

Any suggestions or direction would be greatly appreciated. I don't want to reinvent the wheel if I don't have to.

Attributes are typically used to do the various selections on the page. Upon selecting submit the additional_cart_actions folder files are processed to address othe actions that might need to be performed based on available data (potentially product to be customized). It is of course doable.

The biggest thing to contend with is "retrieval" of any particular data to be able to know at the end all that is involved. Ie. Additional tables to contain data that you don't have previously prepared by not using designated attribute and values. Though you could prep some text attributes that are not visible on the product page and populated by your custom code (javascript, etc...).

Simply recommend laying out what is involved with these custom products, and identifying how the data will be managed/manipulated and planning from there.

JohnH:

Basically, one of the products we sell is custom made. It needs to be made to exact measurements (it's sold by the foot) and has optional features that need to be viewed.

As suggested by mc1-8, this kind of thing is generally handled/made possible via the product attributes.

Selling 'by the foot' isn't an unusual request/requirement, and in its simplest form using the products 'quantity' can be used - 1 quantity = 1ft, 4 quantity = 4 foot, etc, etc. This can be used in conjunction with attributes to select a style or colour.....

JohnH:

I'm just getting started with ZC, but it seems like this particular product is beyond ZC's normal scope.

Good choice of words "normal scope", because some of us would argue that there isn't anything zencart can't do (with a few customisations). :-)

JohnH:

My plan was to develop a wizard app outside of ZC that helps the customer build the product. Once finished, it dumps the product into the ZC cart with the custom specifications.

Any suggestions or direction would be greatly appreciated. I don't want to reinvent the wheel if I don't have to.

I've no doubt that your plan could work, but at the same time, I interpret this as being "A lot of work that is beyond the scope of what we can really help with"

I suggest you take a really good look at the attributes - and possibly even start thinking 'outside the box' (eg, using the quantity field as the number of feet rather than number of products)

If you can't achieve what you want using the attributes themselves, my next suggestion would be to look at the code that already handles this and add/insert your 'wizard app' into that code. This will keep everything 'internal' to zencart and you'll be less likely to suffer unexpected side effects.

Cheers
RodG

Thanks to both of you! Your responses give me hope. I'm nixing the external wizard idea.

I think attributes will handle most of what I'm looking for. I'll need to figure out how to have an image display for each option that is selected. I didn't notice that as a built-in feature.

I think the biggest challenge will be the cost per foot issue. RodG, my first thought was to use quantity for feet, too, but that won't work for two reasons:

1. Customer will need to be able to type in exact sizes like 36.75 feet (only length is needed).
2. Quantity will still need to be calculated. E.g. 5 units at 36.75 feet each X $1 foot.

Thanks again for your help!

JohnH:

I think the biggest challenge will be the cost per foot issue. RodG, my first thought was to use quantity for feet, too, but that won't work for two reasons:

1. Customer will need to be able to type in exact sizes like 36.75 feet (only length is needed).

No problem. Have 'em enter the lengths in inches :-)

JohnH:

2. Quantity will still need to be calculated. E.g. 5 units at 36.75 feet each X $1 foot.

Yeah, that's the biggest fly in the ointment.

Before you rush out to re-invent the wheel though, take a look at this:

http://www.thatsoftwareguy2.com/thatsoft_demo_1/index.php?main_page=product_info&cPath=65&products_id=180

It's a step in the right direction, and although I've not looked any further, it wouldn't surprise me if Scott (or someone else) hasn't already taken this a step further to calculate a price that is dependent on this input data.
OTOH, reading the text description
"where you enter length and width in a text field, and the price is a function of area (length times width) plus a few other product attributes."
It looks like this is exactly what you are seeking.

Cheers
RodG

Thanks RodG! I think that is exactly what I'm looking for! It even allows for decimal fractions.