Checkout image upload problems

[cheesegrits]

A number of our users are reporting problems with uploading images when placing an ad.

They hit Step 4, and instead of the upload form and a "Skip this step" button, they have a blank form with just "Continue". If they do Continue, the final Submit step blows up (although reports about exactly what error are not yet forthcoming).

Our tech support folk have duplicated the problem once or twice, although it seems to be fairly random, and I personally haven't managed to replicate it yet. But the reports are numerous enough and from a variety of users, so I'm confident it's a kosher problem.

From reading the code and the template, it's not obvious how this could happen. Basically $data would have to be empty, and $upphotos would have to be >= $numimages (which is 1 for the package they are using). Which as far as I can tell, would mean there would have to be something already in the prodimages table with the same $listingid in order for $upphotos to have a value ... but this shouldn't be possible if it's a new ad.

So I'm going to comb through prodimages, see what I can see.

Meanwhile, any suggestions gratefully received.

-- hugh

[cheesegrits]

OK ... some more details.

Tracking the problem from one particular user, I can see the orders placed today from him in the class_orders table. BUT there are no corresponding entries in class_listings. Which as far as I can tell means that at this point in step3submit.php:

PHP Code:

            $data['orderID'] = $Orders->generateOrder($orderdata);
            $listingid = $Listings->addListing($data);
            $Listings->setExpiration($productid, $data['orderID']); 


... the generateOrder() succeeded, but the addListing() didn't.

But as there is no actual error checking, it's going to be tough to debug this one without adding some. All addListings() currently does if the query throws an error is to return false. And as per the above lines, step3submit doesn't test for that, it just carries on regardless.

Unless I can actually reproduce this error, about all I can think of to do is add some error handling to addListing(), and write out / mail an error log with the query and the SQL error msg.

-- hugh

[cheesegrits]

Originally Posted by redstar

i am having the same problem, I am the only user right now because I'm still setting up my site. When I go to upload a photo it starts transferring the file and then takes me to a blank page. I even tried skipping the image upload step and then going back and modifying the ad to insert an image, no luck

Not the same problem. Our uploads are working OK, except for some folk who don't even see the upload details box. They just get a blank page with "Continue".

-- hugh

[Lhotch +]

Originally Posted by cheesegrits

Not the same problem. Our uploads are working OK, except for some folk who don't even see the upload details box. They just get a blank page with "Continue".

-- hugh

Have some of your users accessing your site and having the problem disable their virus software for 5 minutes and try again.

[cheesegrits]

Originally Posted by cheesegrits

Unless I can actually reproduce this error, about all I can think of to do is add some error handling to addListing(), and write out / mail an error log with the query and the SQL error msg.

OK, I've added some error handling, so addListing() will mail me if the INSERT query fails. Now I just have to get some of these folk to try again.

Eric ... how about adding a $db->getError(), as well as isError()? Just avoids nastyness like this:

PHP Code:

                        $vars['sqlerr'] = mysql_error($db->dbConn); 


... which obviously does an end run around your abstracted class. Just thinking about future proofing.

And just FYI, the error reporting just looks like:

PHP Code:

                        // $$$ hugh - added error reporting
                        global $Core, $Mailer;
                        $vars = array();
                        $vars['query'] = $sSQL;
                        $vars['sqlerr'] = mysql_error($db->dbConn);
                        $vars['function'] = 'addListing';
            $msg=$Mailer->sendMail($Core->settings['email'], 'queryerr.tpl', $vars);
            return false; 


Might be worth wrapping that up in a function, adding a "Mail on error" admin setting, and providing error feedback to admins on the more important core queries.

-- hugh

[cheesegrits]

Originally Posted by Lhotch

Have some of your users accessing your site and having the problem disable their virus software for 5 minutes and try again.

Already tried that. That's like #3 on the standard script for our support folk for 'unidentified problems'. I think #1 is "Is there gas in the tank?".

Also, I can't think how AV on the client side would explain why I'm getting the class_orders row created, but not the class_listings row.

-- hugh

[Lhotch +]

Originally Posted by cheesegrits

Already tried that. That's like #3 on the standard script for our support folk for 'unidentified problems'. I think #1 is "Is there gas in the tank?".

Also, I can't think how AV on the client side would explain why I'm getting the class_orders row created, but not the class_listings row.

-- hugh

Ive created scripts that are only partially incapacitated by AV software and it was a lot quicker to just run the option by you than to type out a long explanation.

Is this the same site that had issues during the upgrade?

[cheesegrits]

Thanks for moving the unrelated posts.

Well, I got my first hit on the error feedback from addListing, and it's a good one:

Function: addListing

Query: INSERT INTO class_listings (owner, title, shortDescription, description, section, price, display, dateadded, expiration, orderID, featured, pBold, pHighlighted, url) VALUES (5409,'Hay for sale','I have square bale, coastal bermuda hay for sale. Heavily fertilized. Appoximately 50 lbs each.','Cost is $5.00 per bale.',268,'500bale','N',NOW(),'2008-10-29 16:26:28','356','N','N','N','')

SQL Error: Incorrect decimal value: '500bale' for column 'price' at row 1

This happens because in step3submit.php ...

PHP Code:

    if($settings['checkoutRequirePrice']=="Y" && isset($_POST['price']))
    {
        $validate->isEmpty($_POST['price'],"Please enter a valid price");
    } 


... the validation only checks for notEmpty, but the 'price' field is a decimal. So entering anything but a number will pass validation, but puke on the insert.

And the next problem is that if 'checkoutRequirePrice' is NOT set, this will blow up if they enter anything other than a number.

And unfortunately there isn't an isDecimal() validation. There's an isNumber(), but that only checks for is_int().

So here's what I've done to work round this:

Change isNumber() in Validate.php to use is_numeric() rather than is_int().

Forced validation of price thusly:

PHP Code:

        // $$$ hugh - need to validate even if not required, otherwise insert query can fail
    //if($settings['checkoutRequirePrice']=="Y" && isset($_POST['price']))
        if (isset($_POST['price']))
    {
                if ($_POST['price'] == '') {
                    $_POST['price'] = '0.00';
                }
                else {
                    // $$$ hugh - needs to be numeric, or addListing query will puke
                    // (also note I changed the isNumber() func to test for is_number rather than is_int)
                    //$validate->isEmpty($_POST['price'],"Please enter a valid price");
                    $validate->isNumber($_POST['price'],"Please enter a valid price (numbers ONLY, like 49.99 or 20)");
                }
    } 


I'm need to do some more testing, but at the moment it seems to be doing the job.

Oh, and sure enough - without the above mods, if I enter a non-decimal for Price, I get the problem with just a Continue button on step 4.

-- hugh

[cheesegrits]

Originally Posted by Lhotch

Ive created scripts that are only partially incapacitated by AV software and it was a lot quicker to just run the option by you than to type out a long explanation.

Sure. I wasn't complaining, just reasoning through it. I appreciate your input, no disrespect intended.

Is this the same site that had issues during the upgrade?

Yup, but I'm 99.9% sure I've found the culprit (see previous rambling post about decimal validation). Entering anything other than an int/decimal in the price was causing the problem.

FYI, I've spent a week going thru the site, and the only other oddities I've found after the upgrade is that I had no indexes on certain tables ... like class_listings. So I added those by hand. I couldn't swear that my 3.x tables had them in the first place, and a quick check of the upgrade script shows that they don't get added during the upgrade. So this may be down to an original 3.x install issue.

-- hugh

[Mike-N-Tosh +]

Nice catch Hugh! Good solution as well.

I'm surprised that you can do all that with all the "blowing up" going on around you.

-Mike