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 ...

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.

kobra:

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

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

Did you require any DB alterations to install this?

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?

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';

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

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)

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)

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

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.

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

Jus tfor fun, what version of PHP? Mine is 5.2.3

sfatula:

Jus tfor fun, what version of PHP? Mine is 5.2.3

My site is using PHP 5.2.1

Using the foreach-as approach is fine, and is in fact a more efficient construct than the while(list)=each construct. We are moving more toward the foreach approach progressively as code is updated for PHP5.
Thus, making the change you mentioned will be safe.

Yes, I understand that. My issue is this - how many other times is the construct in question used in the code, and, what impact does it have (since they can break also presumably)? Not knowing the true cause, this is not a good feeling. So, I am updating PHP to the current version, re-testing, and, going to post in some PHP forums.

I've tested Zen Cart 1.3.7 on countless servers with varying PHP configurations and never personally encountered the problem reported by regenbauma.
Even downloading his entire site and putting it on a few of my own servers couldn't recreate the problem he reported ... using the while/list/each code construct.

It's odd that it only seems to affect the $_POST data and not other arrays.

If you do find something about it, that will confirm that changing that line will be helpful for your situation.

Future versions of Zen Cart will have fewer while/list/each constructs in favor of foreach constructs.

I hope you are not suggesting what I said is not worth it, it is. Yes, I changed the one line long ago. But, as a programmer who has written a few million lines of code in 30 years of programming, it does not end there. There are two paths:

1. IF the problem turns out to be a PHP bug, then, it is my responsibility to file an official bug report so that the problem can be fixed and not cost tens of thousands of programmers time for whatever odd reason it sometimes happens or
2. IF the problem turns out to be a real difference in the two constructs, and not a bug, then, I need to go through my Zen Cart code and look for other instances that might have the same construct, and, might not be behaving properly.Either way, the problem is far from solved in my book. Simply changing one line that I know is bad and hoping all is ok is not the way to do things. That's all I was saying.

BTW - I have the problem on TWO servers, which are running two different OSes and two different PHP5 versions (though close). So, I am 2 for 2.