POST data is getting lost on the way to actionMultipleAddProduct

[regenbauma]

Im not sure what caused it, and have tried rolling back changes for as long as i remember. This is a 1.3.5 cart that worked fine until I installed latest GCO module ( it think this is what broek it , bit reversing out change has not fixed it)

Problem as follows
..... in shopping cart when productlist is displayed, when product list has form fields for quantity of product enabled example
http://www.scanpancookware.com/featured-products/
http://www.scanpancookware.com/products-all/
when selecting one or more products and submitting
the selected products are not being passed to the cart.
======================================================

i created inserts into error_log to highlight status

function actionMultipleAddProduct($goto, $parameters) {
global $messageStack;
if (isset($_POST['products_id'])) {
error_log("DEBUG - POST of products id is set. Values are as follows :".join(',',$_POST['products_id']));

and when I add values to form fields in product list and submit the log displays

[28-Sep-2007 11:04:15] DEBUG - POST of products id is set. Values are as follows :1,0,0,0,0,0,0,0,0,0

so as a result we never reach

while ( list( $key, $val ) = each($_POST['products_id']) ) {

so products are not added to cart.

I have traced this to death, can anyone suggest what may interfere with the contents of a POST between the form submission and the arrival at the action ?

This system uses magicSEO... i have tried with it enabled and disabled.

drByte looked at this and a few others experts, no luck yet.... please help ...mostly suggestions on what conditions may interfere with the POST data en route to the action ?

By the way ..i dont think its a PHP core config as I have another site on the same server www.swissdiamondstore.com that works fine.

Any help is HUGELY appreciated ...

[kobra]

This is a 1.3.5 cart that worked fine until I installed latest GCO module

Not of immediate use, but for future reference: Always the best course before adding any thing to a live shop is to "Backup" files and DB just for this type of event.

[regenbauma]

Not of immediate use, but for future reference: Always the best course before adding any thing to a live shop is to "Backup" files and DB just for this type of event.

As mentioned in my post, latest changes were rolled back from backup. Problem remained, so it maybe that the problem was there before recent changes and was not noticed. ... thanks for commenting though

[kobra]

Sorry, "rolling back" and restoring all from a backup are read as different to me.

Did you require any DB alterations to install this?

[regenbauma]

Sorry, "rolling back" and restoring all from a backup are read as different to me.

Did you require any DB alterations to install this?

GCO required this change only

update orders set orders_status = 100 where orders_status = 1 and payment_module_code = 'googlecheckout';
update orders set orders_status = 101 where orders_status = 2 and payment_module_code = 'googlecheckout';
update orders set orders_status = 102 where orders_status = 3 and payment_module_code = 'googlecheckout';

[regenbauma]

Believe it or not ....

I have solved this problem by replacing in actionMultipleAddProduct

while ( list( $key, $val ) = each($_POST['products_id']) ) {

with

foreach($_POST['products_id'] as $key=>$val) {

Thanks to drbyte, Dan at IDG , and jiri from magic SEO for taking time to work on it ..these guys are GREAT !! for stepping up to help.

but ... in the end, old fashioned debugging saved the day.

Allan

[DrByte]

I'm glad you've got it working.
I'm still a bit puzzled that it "works", considering that checking the value of $_POST before running the while/list was showing empty during earlier testing ...

Was there anything else that you changed? (or, rather, left changed while doing many tests and didn't back out after testing)

[regenbauma]

I'm glad you've got it working.
I'm still a bit puzzled that it "works", considering that checking the value of $_POST before running the while/list was showing empty during earlier testing ...

Was there anything else that you changed? (or, rather, left changed while doing many tests and didn't back out after testing)

As far as I can tell , i removed all flags that I had inserted during the debug process. I was playing with various structures with ourput to error_log, and quite by fluke when I inserted the foreach, suddenly started to notice that it started to present the output of the $_POST, when i reverted to a while, the $_POST stopped displaying data. I tried a join(',',$_POST['products_id'] and it was showing erratic data.

Even now, after the fact, if I revert to the "while", it breaks it again.

Now why this works fine on 100K other ZC installs, and also on other ZC installs on the same server is beyond me...but for now ill settle for the fact that it works. Just wish I knew what else is broken as a result.

Allan

[sfatula]

So, any explanation of this? The behavour SHOULD be the same, they are equivalent. BUT, on our web site, exactly the same thing happens, replacing the while list each with foreach makes the problem go away. This is soundlng like a PHP bug perhaps? foreach is preferred anyway, but, I do not see any logical reason the 2 statement shoudl not behave the same, but they don't.

[regenbauma]

Well , im pleased that someone else has seen this problem and solved it the same way. I thought I was going crazy. Seems im not :-)

Thanks