I did try to uninstall the discount coupons in 1.39 quite some time ago.
Printable View
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.