I'm stumped....

[Jack_mcs]

I said it usually was the problem. If that is not the case, then I suggest you create a test shop in your hosting account and install the contribution into it. If it works, then it is either something in your live shops files or on the server. If it doesn't work, then you are making a mistake in the installation of the contribution since it does work.

 

Jack

[Guest]

Jack,

 

I have gone as far as wiping the shop completely and re-installing, gives the exact same error on a 100% vanilla install....

[Guest]

Anyone out there willing to help a guy?

[Jack_mcs]

Jack,

 

I have gone as far as wiping the shop completely and re-installing, gives the exact same error on a 100% vanilla install....

Then it isn't a problem with the shop, assuming it is installed correctly. That takes it back to a server related problem.

 

Jack

[Guest]

http://www.oscommerce.com/community/bugs,2...rch,reset%28%29

 

Admin module creating or editing products

Status: Closed

Assigned To: unassigned

Created: 11th March 2002 19:05:52

Last Updated: 15th March 2002 22:18:27

Reporter: pettersen (AT) cpec (DOT) org

Version: 2.2-CVS

Type: Functions & Classes

PHP Version: 4.06

 

Closed Report; No further comments allowed.

 

Hello,

 

I tried both last nights nightly build 03-10 and I also checked out the latest code today and tried a fresh install (I had previously working 0302 or so CVS admin section) Anyways...

 

I get the following error messages when trying to add or edit a product from the Admin section on the categories.php?cPath=&pID=&action=new_product_preview page.

 

 

Warning: Variable passed to reset() is not an array or object in

e:wwwvhostscpec.orgsecureversion2adminincludesclassesobject_info.php on line 17

 

Warning: Variable passed to each() is not an array or object in

e:wwwvhostscpec.orgsecureversion2adminincludesclassesobject_info.php on line 18

 

The price shows up as $0.00USD... If I continue via the INSERT icon I get the following error.

 

 

1064 - You have an error in your SQL syntax near ' , , , null, , , , , now())' at line 1

 

insert into products (products_quantity, products_model, products_image, products_price, products_date_available, products_weight,

products_status, products_tax_class_id, manufacturers_id, products_date_added) values (, , , , null, , , , , now())

 

[TEP STOP]

 

Just any fyi... not sure if anyone else has come across this yet/at all. If it's user error on my end, I apologize in advance. But thought it was worth bringing to your attention.

 

Erik

Comments:

12 Mar 2002 12:51:41 pettersen (AT) cpec (DOT) org

 

I'm really quite baffled... I tried backing up a revision or two (or four) from CVS of the admin/categories.php and admin/includes/application_top.php and still have this issue (which is strange as this *worked* about a week ago or so)

 

I've been able to code around this, but I'm not sure I understand the full weight of my changes (i.e. my head hurts and my eyes are crossed =P )

 

For some reason in the case: new_product and new_product_preview the form post type is set to 'enctype="multipart/form-data"' I'm guessing this is screwing up how PHP's HTTP_POST_VARS are registering the arrays/variables/objects being passed.

 

QUESTION is there a legitimate reason why we have enctype set to multitype here? As far as I can see we aren't actually referencing any files or images (just locations and paths to images if they exist for a product/category) and not the binary image itself...

 

I've removed the references in those two cases to 'enctype="multipart/form-data"' in echo tep_draw_form

 

I'd be much obliged if someone can point out if this is a true BUG or if I have a daft setting in my php.ini that is causing it to choke on this.

 

Thanks!

 

Erik

12 Mar 2002 13:14:18 pettersen (AT) cpec (DOT) org

 

AHA! Here's the dealio.

 

This "issue" is related to how PHP handles the php.ini directive to File_Uploads= off : I'm inferring that it totally disallows or blocks or bombs out the variables if it is File_uploads is set to off and you try to send some multitype encoded POSTS to a PHP page (i.e. PHP doesn't handle it very graceful at all).

 

Turning on File_uploads rectified the issue for me. I have it turned off due to recent PHP vulnerability until I can update the server to php 4.12.

 

Moving forward: I realize we can't code for every configuration under the sun... but I wonder if we could account for sites that DON'T use the admin panel to upload images or don't use product/category images at all. I.E. you'd dump the images in manually using FTP but specify a path to the image.

 

I imagine i'm not alone in not necessarily wanting to grant file_upload privs to php scripts for security reasons... Am I making any sense?

 

This BUG report can be closed, I suppose... but i'd appreciate it if my above thoughts were at least considered for future revisions of OScommerce.

 

regards!

 

Erik

 

Have found this, tried it, and it failed.... On a local install doing the above just disables my images being uploaded, but it still loads the product.... Cmon guys, I need help! ISP have said that nothing changed on their side, but seeing as I didn't change anything on my side and even tried a vanilla install, can't figure this out....