Add to Cart not redirecting to basket page?

Choose the "View / Buy" button for the first product on the following page to get to a product detail page:
http://www.ledwarehouseuk.com/LED-Spotlights.php

...when I click "Add to Cart" it just re-directs to the same page yet "shopping-basket.php" is defined as the redirect in the Add to Cart behaviour.
Is this a bug?

Also, I've been methodically following this tutorial:
http://www.webassist.com/tutorials/Add-dynamic-product-options-II-eCommerce-Series

...and it has worked out pretty well, but there are odd things happening within the wizard dialog boxes:

1) In the "Update Add to Cart button" section (mid-way) it states that you should not bind the colour to any field but, rather, make it updateable. I followed this, but every time I go back into that section Colour has a binding? Should it?

2) When I initially select an option for, for example, Size, it doesn't update in the view so I'm never sure if it has done it or not without either having to click OK and then go back into it again or by clicking elsewhere within the wizard. Again, this seems more like a bug than anything else.

Hope someone can help me. Thank you.
Regards
NJ

Have added error reporting to the page and it's responding with:
"Notice: Undefined variable: ATC_itemQuantity in /home/linweb27/l/ledwarehouseuk.com/user/htdocs/LED-Lights.php on line 129"

Line 129 is:
$ATC_itemQuantity = floatval($ATC_itemQuantity);

A little frustrated by things like this as I've spent a lot of money on these extensions and basic functions like "Add to Cart" cause me problems like this. Why has this error occurred and will I have this problem every time I add an "Add to Cart" button?

Really need this sorted out asap. Should I be submitting this type of thing directly to support? If so, how do I do that?
Thank you.
Regards
NJ

send a copy of the LED-Spotlights.php page please

1) This is fine

2) I dont follow what you mean, please be more descriptive.

The page with the Add to Cart behaviour is LED-Lights.php (attached).

1) It may be fine but it's contrary to the tutorial which is confusing.

2) When I bind something, let's say a database table field, and click "OK", it doesn't immediately update in the list of Bindings view. The only way I can check if it has binded correctly is to click "OK", and then open the Wizard again or click another option in the Bindings list.

the way you have your rsPROD recordset configured, it is filtered on a form post from the previous page.

when the add to cart button is pressed, that form post no longer exists, so the recordset is empty.

add the following form element to the add to cart form on the page:


<input type="hidden" name="LEDid" id="LEDid" value="<?php echo $_POST['LEDid']; ?>" />


1) the tutorial is talking about the initial set up, it does not address reinspecting the add to cart button

2) after making a binding selection, you may sometimes need to select another column to force the binding to stick.

There isn't anything unusual about having the product recordset filtered on a form post, is there? Isn't that how a lot of product list > product detail pages work?

Is the only fix to hand code this? I didn't see anything in the tutorials about the product detail page having to be filtered by a querystring. There is certainly nothing flagged about potential errors if you filter on a form post. Perhaps this should be highlighted to save people like myself hours of wondering what the heck was going wrong? :(

1) I see.

2) It's not sometimes, it's EVERY time.

NJ

"There isn't anything unusual about having the product recordset filtered on a form post, is there?"

Yes, there is.

the most common scenario is to use a query string variable.


the tutorial you are following is one of a series, in the previous tutorials in the series, data bridge is used to create the catalog pages, data bridge uses query string variables to load the details page.

The tutorial may well be one of a series but I've not been following anything prior to it because I'd asked how to add incremental pricing and that was the article I was directed to.

I'm struggling to comprehend your suggestion that having a product recordset filtered on a form post is in any way "unusual".
It certainly isn't unusual and it would be nice, rather than eCart just dying and no longer working, if it could cope with basic stuff like this instead of, after the expense we've had upgrading, finding ourselves back to hand-coding everything. It's a disappointment Jason.

Will I have to hand code this every time I want to have an "Add to Cart" button on a page where the recordset is filtered on a form post?
Can eCart only deal with recordsets that are filtered by querystring?

Thank you.
NJ

"Will I have to hand code this every time I want to have an "Add to Cart" button on a page where the recordset is filtered on a form post?"

yes, if the page uses a form post to load initially, you will need to maintain that form variable by adding it to the cart form


"Can eCart only deal with recordsets that are filtered by querystring?"

It's not a matter of eCart only dealing with record sets that use a query string, it's a matter of persisting the data used to filter the recordset.

eCart will automatically persist the query string for you, if you use a different method, than you will need to add custom code to account for it.

The reality is that when using a master detail page set, the normal procedure is to use a query string.