Just seeking a clarification in the database upgrade step. Do I drop all the 1.53 tables, then import the old 1.39 database into the 1.53 database, then run the database upgrade via zc_install ? That's what I have been doing so far.
Printable View
Just seeking a clarification in the database upgrade step. Do I drop all the 1.53 tables, then import the old 1.39 database into the 1.53 database, then run the database upgrade via zc_install ? That's what I have been doing so far.
Yes a fresh 1.53 installed worked OK with product detail showing at Paypal purchase time. Unfortunately the 1.39 data migration to 1.53 seems to have broken it again. Now the question becomes can I isolate this from the rest of the migrated data so I can still have all my store data ?
Also fails in 1.53 after migrated 1.39 data, and having removed the PayPal Express payment module and then re-installing it. Gets the same result
i.e. "All the items in your shopping basket (see details in the store and on your store receipt)."
Thus is does seem to the the data migration that's caused this problem. This leads me to other issues I was previously having with all those strange  characters appearing in the product descriptions. Having said that a prior test of a newly added product in v1.53 also failed with this same error.
i.e after having migrated the 1.39 data, a test of a newly added product in v1.53 also failed with this same error.
What language(s) are in use on your store? What character sets are used on the product_* and order_* database tables? What is DB_CHARSET (configure.php)? What is CHARSET in each language used in the store?
Thanks for the follow up folks. Well from what I can see utf8_general_ci based on the row statistics in phpMyAdmin. It's a clean install of 1.53 so all the php scripts would be utf8 I imagine. The DB charset is utf8 in both store and admin configure.php files. However when I run the convert_db2utf8.php script, it reports latin1_general_ci for most of the tables and utf8 for a few admin tables.
Everything pretty much seems to work except when I migrate the data from 1.39 to 1.53. Even then most of it works, except the PayPal Express payment module not listing the product line items. The transaction still goes through, but I don't get the line item detail. Before the data migration, even that worked fine. Thus I am fairly certain its the data in the database that might have got corrupt previously, but somehow kept working in 1.39. i.e. line items descriptions came through fine in 1.39 payment process.
Originally I think in v1.39 after the web host upgraded MySQL to 5.3 and PHP 5.4, I seemed to run into problems with that  character appearing all over the place. so then I tried to restore a backup, which didn't fix the issue. So I've been using 1.39 with the problems associated with the server upgrades which seem to include product description data not saving and  characters everywhere.
Once the PayPal POODLE BUG kicked in on Dec 3, I thought I better upgrade to 1.53, but then realized after many hours mucking around, and checking the forum, that the POODLE BUG was not related to the utf8 / iso-8859-1 issue. Anyway having found the POODLE BUG one liner Fix in paypal_curl.php, I was still left with this other issue with concern about the data integrity and  characters. I ran that convert_db2utf8.php fix, but it failed to eliminate all the  characters.
Anyway I'm trying to decide the best approach from here onward. My preference is to conquer this, so I don't have to recreate all the data. I'm also concerned about what impact it could have on my Google ranking if I start from scratch, with new product links and product numbers etc... that don't match up with what's in Google. Thus a few issues of concern.
Getting back to the core issue. All works fine until the database is migrated from 1.39 to 1.53. Oddly though after the data migration, even if I create a new product from scratch, I still get the same problem of no product line detail in the order, for that new product addition. Prior top the data migration, I get the product detail in the order fine.
OK so I have now just run the convert_db2utf8.php script and it now reports all is converted and everything as utf8. Still however the same issue remains and no product detail is being listed in the PayPal transaction. The product detail is only listed in the store transaction receipt.
I only require English for the store. So the utf8 / iso-8859-1 migration might not be required. Anyway I guess it now becomes a question of the best way to work around this. Going back to 1.39 does not seem viable as it has the problems with saving product description data. The servers are upgraded so I guess I can't avoid the effects of that. Running iso-8859-1 character set in a utf8 environment seems problematic.
- POODLE is completely unrelated to UTF8 issues or line-item issues.
- Problems caused by the host upgrading to PHP 5.4 while you were still running 1.3.9 are almost certainly unrelated to line-item issues
Having already done the conversion to utf8, I'd recommend leaving it that way. UTF8 is the contemporary standard, so you'll have fewer headaches if you use utf8.
When this message appears on the invoice, the "cause" will be recorded in Debug Logs if you have PayPal set to Debug Log To File.
It'll be a subtotal calculation problem, either by trying to calculate quantities with products and tax rates, or discounts such as coupons/sales/specials.
Testing the situation on a clean 1.5.3 site must also include your exact configuration of tax rates, product prices, coupons/sales/specials, etc. If you can share that information, and your logs, perhaps we can help you further.
Ahh ok. Hmm it must then be discounts unrelated to the test product which has no discounts or coupons directly attached to it. This log excerpt seems to suggest an issue with discounts, however it seems to total ok. It's just a simple $1 test product.
Dec-15-2014 11:53:12 (1418604792)
getLineItemDetails 6
Discounts have caused the subtotal to calculate incorrectly. Line-item-details cannot be submitted.
Before:Array
(
[AMT] => 1
[ITEMAMT] => 0
[TAXAMT] => 0
[SHIPPINGAMT] => 0
[SHIPDISCAMT] => 0
[HANDLINGAMT] => 0
[INSURANCEAMT] => 0
[L_NAME0] => TEST PRODUCT 3 [438]
[L_QTY0] => 1
[L_AMT0] => 1
)
After:Array
(
[AMT] => 1
[ITEMAMT] => 1
[TAXAMT] => 0
[SHIPPINGAMT] => 0
[SHIPDISCAMT] => 0
[HANDLINGAMT] => 0
[INSURANCEAMT] => 0
[L_NAME0] => All the items in your shopping basket (see details in the store and on your store receipt).
[L_AMT0] => 1
)
=================================
Dec-15-2014 11:53:12 (1418604792)
getLineItemDetails 7 - subtotal comparisons
BEFORE line-item calcs: Array
(
[AMT] => 1
[ITEMAMT] => 0
[TAXAMT] => 0
[SHIPPINGAMT] => 0
[SHIPDISCAMT] => 0
[HANDLINGAMT] => 0
[INSURANCEAMT] => 0
)
AFTER doing line-item calcs: Array
(
[AMT] => 1
[ITEMAMT] => 1
[TAXAMT] => 0
[SHIPPINGAMT] => 0
[SHIPDISCAMT] => 0
[HANDLINGAMT] => 0
[INSURANCEAMT] => 0
[L_NAME0] => All the items in your shopping basket (see details in the store and on your store receipt).
[L_AMT0] => 1
)
=================================
Dec-15-2014 11:53:12 (1418604792)
getLineItemDetails 8
checking subtotals...
Array
(
[calculated total] => 1.00
[AMT] => 1.00
[ITEMAMT] => 1.00
)
-------------------
difference: 0 (abs+rounded: 0)
=================================
Dec-15-2014 11:53:12 (1418604792)
getLineItemDetails 10
subtotals balance - okay
=================================
What if I just delete all specials in the store and re-test ? Just deleted all specials. No that didn't seem to have any impact.