I did try to uninstall the discount coupons in 1.39 quite some time ago.
I did try to uninstall the discount coupons in 1.39 quite some time ago.
Thanks,
007
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?
Thanks,
007
The same data from works fine with paypalwpp.php in v1.39
Thanks,
007
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?
Thanks,
007
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 ?
Last edited by HeyIts007; 15 Dec 2014 at 07:33 PM.
Thanks,
007
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.
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
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.
Thanks,
007
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.
Last edited by HeyIts007; 16 Dec 2014 at 03:50 AM.
Thanks,
007
.
Zen Cart - putting the dream of business ownership within reach of anyone!
Donate to: DrByte directly or to the Zen Cart team as a whole
Remember: Any code suggestions you see here are merely suggestions. You assume full responsibility for your use of any such suggestions, including any impact ANY alterations you make to your site may have on your PCI compliance.
Furthermore, any advice you see here about PCI matters is merely an opinion, and should not be relied upon as "official". Official PCI information should be obtained from the PCI Security Council directly or from one of their authorized Assessors.
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.
Thanks,
007
Bookmarks