items added to Shopping Cart despite errors

[riomaha]

Hi,

I am experiencing an issue where a products requires a customer to upload a PDF file. Only PDFs are accepted. If a customer uploads a PDF file, the cart content shows that the person attached a file and no errors are displayed. However, if the person uploads a JPG file for example and adds to cart, the car content page shows there was an error File type error but the product nevertheless is added to cart without the attribute for the file uploaded/supposed to be uploaded.

I know the issue is within classes/shopping_cart.php. I can modify the file to reject to add to cart but the only way I figured how to do that is by emptying the cart and showing your cart is empty. Ideally, I would like to show there was an error and send the user back to the product page where most of the attribute s remain filled and they only need to attach the proper file format.

I did try to implement the changes in that file from ZC 1.5.7C but that didn't change the outcome.
any advise would be greatly appreciated it.

[mc12345678]

In the attributes controller for the product, is the file upload attribute marked as required? (believe it is the red box on the right side of selections.)

[riomaha]

In the attributes controller for the product, is the file upload attribute marked as required? (believe it is the red box on the right side of selections.)

It is indeed marked as required. Also that feature only prevents you from adding to cart if you didn't select a file to upload. Shopping_cart.php. Upload.php should be providing conditions (e.g. File extension) to shopping_cart.php.

I know my installation has many modules but none that would affect Shopping_cart.php file other than Canada post dimensions.

[mc12345678]

It is indeed marked as required. Also that feature only prevents you from adding to cart if you didn't select a file to upload. Shopping_cart.php. Upload.php should be providing conditions (e.g. File extension) to shopping_cart.php.

I know my installation has many modules but none that would affect Shopping_cart.php file other than Canada post dimensions.

So, I have no doubt that there is an issue "in there" and that its unrelated to other changes. Meaning, I asked that question to be sure at least it was set. Now the trick is how to get the software to respond the same way with a "failed" upload as it does with any other attribute "mismatch"....

When your store is doing athings normally, does the grocery cart show after adding a product or does the "product" page show?
Do you have any test product where there is no upload option but you have an attribute that is setup with a "please select..." option (sort order 0, display only, default) where you could try adding the product without making a selection and see if the store operates like you expect/want? Again, I ask because it appears that what needs to happen is for the store (likely shopping_cart) to act the same for both issues. There have been a lot of little tweaks here and there for some of the other "features" and perhaps something was missed for file uploads... I'm of course asking so that I can make the same configuration and duplicate as well as possibly suggest a solution.

So, your continued patience and support would be helpful. :)

[riomaha]

my apology for any delayed replies. While most of my items do require a file to be uploaded, I have a test product that only requires an attribute to be selected. User must be on the product details page to be able to add to cart (cannot add to cart from categories or any other listing). If I ty to add the product to cart without entering the required attribute/option, It goes to the cart but says your cart is empty.

[riomaha]

In testing I replaced the file shopping_cart.php with one from 1.5.7C (unmodified) and I tested adding to cart a product with no options selected. I was not able to add and it asked me to make sure I select an option. I tested with a product that requires an uploaded file and I selected A JPG which is not permitted and the product was added to the cart without the attribute.

I can only conclude that indeed a code check is missed for file upload.

[riomaha]

I guess I am a little hasty when writing. To recap if the attribute to upload a file is left blank, the product fails to be added to cart and asks that you select a file to upload. (so far so Good).

If the file uploaded is not within the approved file extension. the product is added to cart even though an error message displayed on top of cart "Error: File type not allowed. .pdf".

I reviewed the shopping_cart.php and compared it to version 1.5.6C. 1.5.7, and 1.5.7C and all behave the same way regardless of which copy of shopping_cart.php I replaced it with. That leads me to think that what might be missing is a function to check the uploaded file to ensure that it conforms to the site/store requirements (upload.php and shopping_cart.php).

[riomaha]

I guess I am a little hasty when writing. To recap if the attribute to upload a file is left blank, the product fails to be added to cart and asks that you select a file to upload. (so far so Good).

If the file uploaded is not within the approved file extension. the product is added to cart even though an error message displayed on top of cart "Error: File type not allowed. .pdf".

I reviewed the shopping_cart.php and compared it to version 1.5.6C. 1.5.7, and 1.5.7C and all behave the same way regardless of which copy of shopping_cart.php I replaced it with. That leads me to think that what might be missing is a function to check the uploaded file to ensure that it conforms to the site/store requirements (upload.php and shopping_cart.php).

I played around with the upload.php file in particular this code

     }
            if (substr($file['name'], -9) == '.htaccess' || (sizeof($this->extensions) > 0 && !in_array(strtolower(substr($file['name'], strrpos($file['name'], '.') + 1)), $this->extensions))) {
                $this->message_stack(ERROR_FILETYPE_NOT_ALLOWED . ' .' . implode(', .', $this->extensions), 'error');

                return false;

            }

if I mask return false;

// return false;

the product is still added to cart despite being of the wrong file format and I do get the error on top but I also get the product attribute/option listed in the cart with the extension .jpg. Previously, if the file type is not allowed, then the attribute doesn't get listed in the cart even thought a file was selected.

If I change the code to

 return true;

It adds the product to the cart despite the error, shows there was an error, and it adds the product option with the file ID but without the extension.

If I changed the code to

     if (substr($file['name'], -9) == '.htaccess' || (sizeof($this->extensions) > 0 && !in_array(strtolower(substr($file['name'], strrpos($file['name'], '.') + 1)), $this->extensions))) {
                $this->message_stack(ERROR_FILETYPE_NOT_ALLOWED . ' .' . implode(', .', $this->extensions), 'error');
//start new line             
   $this->$messageStack->add_session('header', ERROR_FILETYPE_NOT_ALLOWED . ' ' . UPLOAD_FILENAME_EXTENSIONS, 'error');
//end new line
                return false;

            }

and upload a JPG file which is not approved file format, I got the cart to prevent me from adding to cart and keep at product page till I fix/upload a proper file.



Some feedback would be great on the impact of adding the line where it is.

[riomaha]

Scratch that. I was no closer to a solution. After another test, it seems to not work. I realized that my mouse was/is not clicking properly. still looking into this issue.

[mc12345678]

Scratch that. I was no closer to a solution. After another test, it seems to not work. I realized that my mouse was/is not clicking properly. still looking into this issue.

Darn, I had hoped you had solved it and I wouldn't have to look into it (I have extreme curiousity towards difficult issues.)

I know there were some "core" changes to upload filetype identifications in 1.5.7, but I don't recall seeing the complete impact/changes made to support that. I thought it ended up being basically a default set of file extensions with an override by constant definition instead of a configuration in the admin configurations... Also not sure if/when there may have been the sought after user friendliness but doesn't mean it shouldnt be there. :)

Only real concern I have with "restoring" that is if it makes it so easy to cycle through the attempts, does anything about the unacceptable file get retained on the server?