Printable View
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.
I can't duplicate your symptoms on a clean 1.5.3 site. So there's no "fix" to publish.Quote:
Originally Posted by HeyIts007
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.
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 addonQuote:
Originally Posted by DrByte
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
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.Quote:
Originally Posted by HeyIts007
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.Quote:
Originally Posted by HeyIts007
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.
I did try to uninstall the discount coupons in 1.39 quite some time ago.
I've debugged /includes/modules/payment/paypalwpp.php and checked the line 1360 that says;
if (strval($optionsST['ITEMAMT']) <= 0) {
I'm getting a value of "0" for strval($optionsST['ITEMAMT']
Does that tell us something more?
The same data from works fine with paypalwpp.php in v1.39
Somehow this new 1.53 paypalwpp.php doesn't like my old 1.39 data in one form or another. Whether its shipping or currency or something else?
re; 1.53 paypalwpp.php
Could it be a software / data anomaly? $optionsST['ITEMAMT'] seems to be ending up with a zero value which is resulting in this issue.
This is then failing a later test: if (strval($optionsST['ITEMAMT']) <= 0)
A debug mod of if (strval($optionsST['ITEMAMT']) < 0) resulted in the correct product line detail being transferred to PayPal. Obviously this is not necesserily a fix, however it highlighted to me, where this is failing. Perhaps this can shed some light on the 1.39 migrated data related cause? Can a zero value on any array item cause this problem? Could the 1.39 data fail to conform to a data format expected by 1.53 thus resulting in this anomoly?
Given I've been able to make this work in a debug test by a simple code change of ( < 0 instead of <=0 ), this should reveal something to anyone familiar with the code.
What are the implications, if I need to use this code mod for my special 1.39 migrated data case, failing any other solution becoming available to me ?
1. More importantly, why is your site the one encountering such problems?
This strongly suggests the problem is with things very unique to your site, and not with Zen Cart as a whole. Thus changes to Zen Cart core code would be highly unrecommended; instead, fixing the problems unique to your site would be the best solution for the long term.
2. There were no significant data changes between 1.3.9 and 1.5.3 that would affect payment handling. The significant changes were related to storing passwords with a stronger encryption protocol, and that has nothing to do with the things you're posting about.
I have no idea why these problems exist, hence this process of discovery. It's evident it's the data that's resulting in this issue, as prior to the database being upgraded, this payment process worked perfectly without any code mods, bar the separate PayPal POODLE issue which is a one line comment out mod in paypal_curl.php. No other mods have been made to this freshly unzipped 1.53 code and I even used the default template that comes with it, just in case.
So why is there a zero data value that's resulting in this failure? I don't know the answer to that, however I thought it might point to the possible cause. How do you back track from that point. Seems to me that to solve this problem one needs to go backwards in the processing steps right to the data source. Surely someone familiar with the code can advise on that. There were some database upgrade exception warnings which I will follow up shortly.
Below are the database upgrade anomalies reported. The upgrade script indicated in most cases the failed statements can be ignored.
=====================================================================
62 statements processed.
Note: 4 statements ignored. See "upgrade_exceptions" table for additional details.
13 statements processed.
34 statements processed.
16 statements processed.
SKIPPED: Cannot drop index page_accessed on table admin_activity_log because it does not exist.
SKIPPED: Cannot drop index access_date on table admin_activity_log because it does not exist.
SKIPPED: Cannot add index idx_page_accessed_zen to table admin_activity_log because it already exists.
SKIPPED: Cannot add index idx_access_date_zen to table admin_activity_log because it already exists.
=====================================================================
I'm thinking these are unrelated to the PayPal payment issue outlined.
Correct.Quote:
Originally Posted by HeyIts007
re; 1.53 paypalwpp.php
So what does this actually mean if (strval($optionsST['ITEMAMT']) <= 0) when the value is zero ? as opposed to being greater than zero ? i.e. what does it indicate about the transaction ? the shopping basket etc... Working backwards from here could identify the initial data related cause.
re; 1.53 paypalwpp.php
"All the items in your shopping basket (see details in the store and on your store receipt)."
Wondering if it's some kind of array element mismatch, as in my debug testing using if (strval($optionsST['ITEMAMT']) < 0) instead of the <= 0 actually outputs the product line detail to PayPal, however it also includes the product code in square brackets [ ] in the product detail which seems odd. Almost seems like some kind of mismatch somewhere, be it an array element or how its accessed or something else etc...
E.G. With the debug test mode of < 0 it's outputting "TEST Product [123]" with 123 being the product code, instead of just "Test Product" as it used to. This brings me back to my previous question regarding statement if (strval($optionsST['ITEMAMT']) <= 0) and what a zero value as opposed to a greater than zero represents in the shopping basket transaction?
Definitely seems this relates to the crux of the issue though and working backwards from here should reveal more about the cause.
re; v1.53 paypalwpp.php
What's the name of the product detail array ? i.e. that forms the product line detail e.g. "TEST Product [123]" etc...
re; v1.53 paypalwpp.php
Why is the code appending the product ID to the product name ? Is that the new format ? or is that leftover debug code not removed?
$optionsLI["L_NAME$k"] = $order->products[$i]['name'] . ' [' . (int)$order->products[$i]['id'] . ']';
There's no leftover debug code there.
re; v1.53 paypalwpp.php
It's evident that;
re;
if (strval($optionsST['ITEMAMT']) <= 0) {
If I just make it <0 as follows;
if (strval($optionsST['ITEMAMT']) < 0) {
The product line detail then gets displayed in my order at least.
However then looking at the below code.
$optionsLI["L_NAME$k"] = $order->products[$i]['name'] . ' [' . (int)$order->products[$i]['id'] . ']'; is producing "TEST Product [123]" in the line item output. So why is that ? Normally the line item output is just "TEST Product"
Appending . ' [' . (int)$order->products[$i]['id'] . '] is resulting in the [123] in the product line item output which is then showing in the PayPal order detail.
re; v1.53 paypalwpp.php
"All the items in your shopping basket (see details in the store and on your store receipt)."
What are the implications of applying these two code adjustments to correct the PayPal missing product line output issue in my v1.53 that seems to have resulted from data migration from 1.39 ?
1.
if (strval($optionsST['ITEMAMT']) <= 0) {
Becomes: if (strval($optionsST['ITEMAMT']) < 0) {
2.
$optionsLI["L_NAME$k"] = $order->products[$i]['name'] . ' [' . (int)$order->products[$i]['id'] . ']';
Becomes: $optionsLI["L_NAME$k"] = $order->products[$i]['name'] ;
These two adjustments correct the PayPal product line output problem in my case, however will applying them cause other problems?
So, this question/request was made a while back to try to answer the question of why the database of your existing store upgraded/brought into your rebuilt store is causing the issues that you have observed and the request remains unanswered. Now the solution being proposed is to 1, change the way the code is written (which is not unheard of) but based on some previous experience (huh, when I last drove my car 50 mph down this road, with my eyes shut nothing happened. Where did that car come from?). If you take the time to identify why this issue is happening on your site (or provide the information to help others do the same) then the "problem" whether on your site or in the core code can be resolved.
Although I only briefly looked throught that portion of the paypal code, it seemed to me that that section was about verifying that things were set up correctly to move forward with the sale/purchase. I'm only calling from my memory of yesterday as I hadn't taken the time today to look through the code to try to determine what it is you are not providing...
When you goto modules->Order Total in the admin panel, what modules are listed that do not have a red circle? What are their sort orders and are they green or some other color?
re; v1.53 paypalwpp.php
"All the items in your shopping basket (see details in the store and on your store receipt)."
Thanks for looking at this. Yes I've spent a week on this issue and not identified a forum solution for my case. Shipping and Total are green, everything else is red. The only 1.53 code change made was the commenting out of the SSL3 reference in paypal_curl.php to address PayPal Poodle BUG. From there it was working perfectly until the 1.39 data migration. Seems like perhaps there's some kind of data mismatch in the array processing.
Does the data migration also update PHP coding? I will presume not at this stage. I'm not a PHP expert and don't know how all this ZenCart code works, but failing a provided solution, I'm having to try to come up with my own. That is why I have sought to clarify if these two proposed code adjustments which correct the PayPal product line output problem in my case, will cause other problems if implemented on my live site? I'm asking if there's a car coming I guess. I expect someone familiar with this code would know the answer to that.
To further clarify re; your question about the modules settings. The following two are green. The rest are red.
Shipping ot_shipping 200
Total ot_total 999
In each of those, what are the settings? (We are talking about the settings of either the imported old data or the old store, they ought to be the same.)Quote:
Originally Posted by HeyIts007
Yes both the 1.39 site and the 1.53 site have the same module settings. Both green on the below two module items only. Both with the same sort order.
Shipping ot_shipping 200
Total ot_total 999
Okay, so I've setup a store with these two order total modules active with the same sort orders. In shipping I have free shipping disabled, but a value of $50 for the minimum needed to obtain free shipping and free shipping to apply to national orders. These settings have not yet been provided, so I am publishing what I see there.
Now the question really is... Where is it that you are seeing this "error" that you are concerned about? What is it affecting?
I've found a file that contains the error message you describe, but I have not found any problems with processing a payment. So, curious, what is the last 5 pages all about?
re; v1.53 paypalwpp.php
The whole thread is about this message and the fact that the product line detail is not being included in my PayPal order. Instead I get the below message in the Paypal order details.
"All the items in your shopping basket (see details in the store and on your store receipt)."
That has been made clear at the outset. The question remains the cause, however it's evident its the data migration that has resulted in the message below. The problem occurs after the 1.39 to 1.53 database upgrade.
Thus in 1.53 no product order detail appears in the Paypal receipt. Instead I just get the above message as previously described. This was not occurring in v 1.39
The product line data exists, but with the PHP code in paypalwpp.php is not allowing it through to PayPal.
This seems to be a result of the code line test: if (strval($optionsST['ITEMAMT']) <= 0) as when I debugged the data is was a value of zero so it was failing this code line test.
Yet the data is there, because if you use test: if (strval($optionsST['ITEMAMT']) < 0) i.e. remove the "=" sign component, the product detail gets transferred to PayPal successfully and then the product order detail is shown in the PayPal receipt, instead of that message above.
The above error message for lack of a better description, is in the PayPal receipt that is emailed to the seller and customer. It's also shown in the order detail in PayPal when you log in as a customer.
re; v1.53 paypalwpp.php
For example, instead of showing on the buyer and seller PayPal receipts that Joe blogs has ordered 3 Widgets of a given kind, it's showing that message below.
"All the items in your shopping basket (see details in the store and on your store receipt)."
Where as in v1.39 I got the product detail of 3 widgets on the PayPal receipt as expected. It relates to the database upgrade as it worked fine before the database upgrade step. The data structures don't seem to be correlating between 1.39 and 1.53.
Is paypal setup to authorize only or to accept payment upon checkout? I believe there are still unanswered questions posed by Dr. Byte related to this. I haven't gone back to try using a sub-total option, but am thinking that might pose a solution.
I'm using Paypal Express Checkout which is set for Final Sale. The payment goes through fine. It's just that the product order detail is missing and replaced by that message.
i.e. "All the items in your shopping basket (see details in the store and on your store receipt)."
I've added the subtotal module and initial testing suggests that seems to help address part of the issue ( i.e. gets rid of that message ), however I'm still getting the product code passed in square brackets passed along with the product description.
Thus I'm getting something like this; "Test Widget A [123]" passed to PayPal and appearing on the PayPal receipts, when I should be getting just "Test Widget A"
Glad the error message went away.Quote:
Originally Posted by HeyIts007
1. Is the sort order for sub-total less than or greater than your shipping sort order?
2. Or more appropriately asked: what is the sort order for the sub-total?
3. So what's the problem with including what appears to be an additional unique product identifier? [123]?
1. The sub-total sort order is greater than all shipping sort orders which are all zero.
2. The sub-total sort order is: 100
3. The unique product identifier e.g. [123] appended to the product description, wasn't present in the v1.53 PayPal receipts prior to the v1.39 database migration. It seems odd that it's appeared after the data migration. It doesn't appear to be like the regular PayPal receipt output for either v1.39 or v1.53. Also it might create a bit of confusion in the product detail and it looks a bit odd also. It doesn't seem like standard out of the box v1.53 functionality, so I would just like be able to switch it off.
That's been present since v1.5.0. If I recall correctly it was added because many merchants were reporting that they had multiple products of similar name and needed a way to differentiate, to specifically identify which exact product was in the order.Quote:
Originally Posted by HeyIts007
It has no bearing on calculations. It's display-only.
Oh I didn't notice it before. Is there a non-coding way to turn it off ? e.g. like an option in ZenCart admin? or a config file etc ..?
No. You're the first to ask about it since 1.5.0 was released in 2011.Quote:
Originally Posted by HeyIts007