Product Name Not Appearing in Detail Line Items

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.

HeyIts007:

I'm thinking these are unrelated to the PayPal payment issue outlined.
Correct.

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

HeyIts007:

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