I've just upgraded from v1.39h to v1.53 and am now getting this kind of message also. I've never had this problem in v1.39. Message is as follows.

"All the items in your shopping basket (see details in the store and on your store receipt)."

Why should this be a problem now ? The PayPal receipt totals $89.70 consisting of 3 store receipt products of $30.95 + $16.95 + $15.95 + $25.85 shipping

I have a similar problem after upgrading from 1.39h to 1.53 a few days ago. i.e. the line item detail is missing in the Paypal order receipt.

"PayPal Error: "All the items in your shopping basket (see details in the store and on your store receipt)."

My v1.39 is still working fine but 1.53 with migrated / upgraded 1.39 to 1.53 database is producing this error. I thought 1.53 would be better, but so far I'm not having much luck with it. Very frustrating. Anyone got any ideas how to fix this issue?

Is the cause likely to be coding or database or both ? or settings? I'm using PayPal Express Payment module in 1.53, same as in 1.39.

I'm not using any strange pricing values either. Even a simple $1 test product results in this problem.

I've isolated this apparent fault to the file: /includes/payments/paypalwpp.php. i.e. the v 1.53 version fails and produces that PayPal message; "PayPal Error: "All the items in your shopping basket (see details in the store and on your store receipt)."

The v1.39 version of this same file **paypalwpp.php ** seems to work fine when run with the rest of the v1.53 code. i.e. I don't get the above message, but instead get the product line item detail in the PayPal order detail on the PayPal site and in the PayPal order receipt.

The question now becomes what in this file is resulting in this apparent BUG ? is it the code or again is it the old data that it can't process ? I'm leaning toward the file itself. Even a new product created in 1.53 produced the above error.

I ran WinMerge against the 1.39 and 1.53 versions of paypalwpp.php. Suffice to say this file seems to relate to this apparent, but not confirmed BUG.

**Correction to above. ** I meant: /includes/modules/payment/**paypalwpp.php **

In /includes/modules/payment/**paypalwpp.php ** Section **"Prepare subtotal and line-item detail content to send to PayPal" ** is an area I would be querying, but I don't know how all this code works.

re; "PayPal Error: "All the items in your shopping basket (see details in the store and on your store receipt)."

Is there a published fix for this v1.53 **paypalwpp.php **problem ?

I would prefer not to use the old v1.39 paypalwpp.php file, if possible.

HeyIts007:

re; "PayPal Error: "All the items in your shopping basket (see details in the store and on your store receipt)."

Is there a published fix for this v1.53 **paypalwpp.php **problem ?

I would prefer not to use the old v1.39 paypalwpp.php file, as I seem to get email errors using this old code when run on the 1.53 site.
I can't duplicate your symptoms on a clean 1.5.3 site. So there's no "fix" to publish.

And, no, you should NOT use the 1.3.9 version of the file on a v1.5.3 site, else you will run into several problems.

Most odd.

I might try uninstalling the PayPal Express payment module and then manually setting it up, instead of relying on the migrated payment module data from v1.39

Failing that I will try another fresh test install and manually setup the payment module instead of using the migrated payment module data from 1.39

Could also be exacerbated by all the addons and customizations you've made to the site vs original ZC code. Especially anything that affects prices, taxes, coupons, calculations, etc.

DrByte:

Could also be exacerbated by all the addons and customizations you've made to the site vs original ZC code. Especially anything that affects prices, taxes, coupons, calculations, etc.

Perhaps, however I've not made any changes related to the payment module and only had a few addons like a slide show addon and the Google CAPTCHA addon

Even with a fresh 1.53 install I was getting this problem, bar the PayPal mod for the POODLE BUG which I made. i.e. commenting out the // CURLOPT_SSLVERSION => 3, line. i.e. in includes/modules/payment/paypal/paypal_curl.php

No other changes were made to the code in this test, yet I still got this problem, which is why I've been wondering if the payment module data migration might have something to do with it. Anyway time will tell hopefully.

Yes a fresh 1.53 install with POODLE BUG Fix worked OK with the product line detail displaying at purchase.

I will try to migrate the 1.39 data again ( using the database upgrade install option ) with no code changes and see what happens.

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

HeyIts007:

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.
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.

HeyIts007:

i.e. "All the items in your shopping basket (see details in the store and on your store receipt)."
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.