Jump to content
  • Checkout
  • Login
  • Get in touch


The e-commerce.

PHP 5.x to 5.4.45 = can't checkout with some products

Recommended Posts


I recently moved my osC 2.3.4 BS (QTPro, AJAX Attribute Manager, Attribute sort order) to a new host and with that came a new version of PHP: 5.4.45

It's causing all sorts of problem, or at least I believe that the PHP version might be the cause. I've fixed a couple about bad integers, and data too long for some columns (not getting truncated as before).

One problem I can't seem to figure out is that the "Confirm Order" button (checkout_confirmation.php) doesn't work when some specific products are in the cart. It seems to be related to the number of attributes/options the product has. Namely it looks like I can't checkout with products that have more than 2 attributes?

Could that be caused by some PHP difference?
How would I go about debugging the Confirm Order button? to see what the problem is. Google Chrome's console doesn't show anything, but I might be using it wrong.

Any tips?
Any other bits of PHP that likely would need to be tweaked given my situation?


Link to comment
Share on other sites

That version of oscommerce should be able to run on 5.6, maybe even 7.0, so I don't suggest messing with 5.4.  But whichever version, you need to find the error for the failure. It might be that the new version of php doesn't have some extension installed. But without knowing the failure, you would just be guessing. So look at the error_log file for the shop, if it exists, or ask your host to look at the servers error log, assuming you don't have access to it.

Support Links:

For Hire: Contact me for anything you need help with for your shop: upgrading, hosting, repairs, code written, etc.

All of My Addons

Get the latest versions of my addons

Recommended SEO Addons

Link to comment
Share on other sites

That's an interesting bit @ecartz! I'm on "MySQL 5.5.5-10.2.31-MariaDB" now, I did not note the version of MySQL I was on before, so I don't know if it's any different now. (never taking a host move lightly again...)

The trunc error showed up at checkout, users got the error:

1406 - Data too long for column 'products_options_values' at row 1

insert into orders_products_attributes (orders_id, orders_products_id, products_options, products_options_values, options_values_price, price_prefix) values ('29044', '74131', 'Packaging', 'This is a gift, please package it pretty', '0.0000', '')


Because 'This is a gift, please package it pretty' is longer than 32 char which is the length of that field. On our previous host it just truncated the string at the 32nd char. I "solved" this by simply making the field larger, but that's probably not the best way to go.

Are there known modifications that need to be done to accommodate MySQL 5.5.5-10.2.31-MariaDB? that might be the source of my other problems.


Link to comment
Share on other sites

1 hour ago, cinolas said:

I "solved" this by simply making the field larger, but that's probably not the best way to go.

Making that field VARCHAR(255) is reasonable.  You can also change

                                'products_options_values' => $attributes_values['products_options_values_name'], 


                                'products_options_values' => substr($attributes_values['products_options_values_name'], 0, 255), 

in checkout_process.php.  Change the 255 to whatever you want the maximum length to be (255 is the maximum length for a MySQL VARCHAR column to have a single byte length).  You can use mb_substr instead of substr if your PHP includes it (might be necessary if your site uses non-Latin characters). 

Or change the MySQL settings to not throw an error (so it truncates and warns instead).  Sorry, I said version, but it looks like a settings issue instead.  The version may have changed the default setting.  I'm not up to date on the version differences at the moment.  My main contribution here is to point out that column auto-truncating is a MySQL thing rather than a PHP thing.  So mucking around with PHP versions or settings is unlikely to change things.  MySQL settings might.  And of course you can work around the issue by changing PHP code not to pass values that MySQL will find to be too long. 

You would do the substr before any tep_db_input (tep_db_perform will automatically do the tep_db_input later) and preferably before tep_db_prepare_input.  E.g.

$value = 'Whatever';
$shortened = substr($value, 0, 255);
$prepared = tep_db_prepare_input($shortened);
$input = tep_db_input($prepared);


tep_db_input(tep_db_prepare_input(substr($value, 0, 255)))

It is (security) critical to do the tep_db_input last (which places it first if you do all of them in the same statement). 

Always back up before making changes.

Link to comment
Share on other sites

Thanks @ecartz! Excellent suggestions. I've asked my host manager to change that MySQL option.

Still waiting on the error_log...

I enabled error display on page using this:

ini_set('display_errors', 1);
ini_set('display_startup_errors', 1);

But it only shows the errors that occur while loading the checkout_confirm page. All of which are Notices about constants already being set. I get no more feedback when pressing the Confirm Order button since nothing happens.

Another problem I'm having is product attributes not showing up on the shopping cart page. It shows everything else, even the correct number of - under the product name where the attributes should be listed, but there's nothing after the dash. I only mention this here in case it's a known symptom of a problem that might be related.

Link to comment
Share on other sites


This topic is now archived and is closed to further replies.

  • Create New...