PayPall Express - Shipping and Billings Address problems using WOZ addon

[thomasjay]

Are many painful hours of looking for the problem I finally found the culpurt

Wordpress addon for Zen Cart.

No idea why it would be breaking it by as soon as I uninstalled the woz it started working.

I do not need any advanced features of wordpress in by blog.

Is there a simple way to include the content of this page
http://weaselandfibb.com/blog/ with formatting within by index page?

[pkfrizzlefry]

Yes having the same issue since i installed WOZ, it seemed like such a nice contribution till these errors

I was getting 10571 missing address1

After like 12 hours i finally figured out it was WOZ (since i installed multiple contribs)

The file thats causing this issue is init_woz.php

Add something like this to the top of it (so the WP() doesnt get executed on payment processing)

I replaced

if (defined('WOZ_CONFIG_STATUS') && WOZ_CONFIG_STATUS == 'true')

with

if (defined('WOZ_CONFIG_STATUS') && WOZ_CONFIG_STATUS == 'true' && $_GET['main_page']=='wordpress')

And it all jives now...wish i figured it out earlier!!

Good luck

Pete

[shutterdrone]

We had the same issue with our store, unfortunately we couldn't make the change noted, because having the wordpress side-bars are essential to our site layout (they provide documentation, news, videos, and such that are essential to informing our customers), and making that change breaks the sidebars.*

Notably, I had no choice but to rapidly fix it, as most (about 70%) of our paypal express orders were failing for this reason.

I can't really tell you why _all_ of them don't fail, this is the part that has me completed confused.

(the following is related to paypalwpp.php)

Namely, the issue seems to be that when paypal returns the shipping address (and it always returns the shipping address, it seems), the variable $order is damaged in such a way that ec_step2() cannot populate the order info. This results in it finding that the override address does not match the order address (thinks it was changed at paypal), and since addAddressBookEntry() does not check if its a valid address, adds a blank address, and sets the sendto id to the blank address book entry.

Then, you know what happens when the final step goes back to paypal...

Here's what to look for in the logs to validate this:

Oct-04-2010 02:04:56 (1286157896)
ec_step2_finish - 1
START: paypal_ec_payer_info= Array
(
    [payer_id] => xxxxxxxx
    [payer_email] => useremail
    [payer_salutation] =>
    [payer_gender] =>
    [payer_firstname] => Joe
    [payer_lastname] => User
    [payer_business] =>
    [payer_status] => verified
    [ship_country_code] => US
    [ship_address_status] => Unconfirmed
    [ship_phone] =>
    [order_comment] =>
    [ship_name] => Joe User
    [ship_street_1] => 111 Fake Street
    [ship_street_2] =>
    [ship_city] => Houston
    [ship_state] => TX
    [ship_postal_code] => 77009
    [ship_country_name] => United States
)

=================================

Oct-04-2010 02:04:56 (1286157896)
ec_step2_finish - 2
country_id = 223 United States US
address_format_id = 2
state_id = 57 (original state tested: TX)
country1->fields['countries_id'] = 223
country2->fields['countries_id'] = 223
$order->customer =
=================================

Oct-04-2010 02:04:56 (1286157896)
S2 1:
1
=================================

Oct-04-2010 02:04:56 (1286157896)
addAddressBookEntry - 1
address to add:

=================================

Oct-04-2010 02:04:56 (1286157896)
addAddressBookEntry - 2
added address #186
SESSION[sendto] is now set to 186
=================================

Oct-04-2010 02:04:56 (1286157896)
S2 2:
186
=================================

Now, the odd part for me was that findMatchingAddressEntry() validates its input data, so won't search for a blank address, but addAddressBookEntry() does not! This means every time a user encounters this issue, they add a new blank address to their book.

So, I added the following line to paypalwpp.php, just inside the addAddressBookEntry() function:

    if ($address_question_arr['street_address'] == '') return false;

Additionally, I commented out the part that later tries to load the overridden address from the before_process() function:

/*
      if ($order->delivery['street_address'] != $_SESSION['paypal_ec_payer_info']['ship_street_1'] && $_SESSION['paypal_ec_payer_info']['ship_street_1'] != '') {

        $this->zcLog('compare addresses:', $order->delivery['street_address'] . ":" . $_SESSION['paypal_ec_payer_info']['ship_street_1']);

        $_GET['markflow'] = 2;
        if (($address_arr = $this->getOverrideAddress()) !== false) {
          $this->zcLog('Forcing Override',  print_r($address_arr, true));
          // set the override var
          $options['ADDROVERRIDE'] = 1;
          // set the address info
          $options['SHIPTONAME']    = $address_arr['entry_firstname'] . ' ' . $address_arr['entry_lastname'];
          $options['SHIPTOSTREET']  = $address_arr['entry_street_address'];
          if ($address_arr['entry_suburb'] != '') $options['SHIPTOSTREET2'] = $address_arr['entry_suburb'];
          $options['SHIPTOCITY']    = $address_arr['entry_city'];
          $options['SHIPTOZIP']     = $address_arr['entry_postcode'];
          $options['SHIPTOSTATE']   = $address_arr['zone_code'];
          $options['SHIPTOCOUNTRYCODE'] = $address_arr['countries_iso_code_2'];
        }
      }
*/

This means we'll never get in our cart the new address if a user changes it in paypal, but we just tell 'em to make sure they enter the right one in the shipping address.

We force logins to checkout, namely because each sell is fairly large, and we'll live with a slightly lower conversion rate, because ultimately drive-by's are just support nightmares for what we're selling.


I hope this helps someone else who needs to deal with WOZ and Paypal express!


* - of course, with this issue, we're going to have to hard-code the sidebars soon and only use WOZ when one of the pages is clicked on, I just needed to get everything working with minimal impact to the site until I can get some time to fix it all correctly.

[DrByte]

Notably, I had no choice but to rapidly fix it, as most (about 70%) of our paypal express orders were failing for this reason.

I can't really tell you why _all_ of them don't fail, this is the part that has me completed confused.

Perhaps a comparison between the logs for the failing vs non-failing transactions might be useful?
Namely what is the value returned from PayPal for ADDRESSSTATUS ?
If it's returned as "NONE" then Zen Cart treats it as a blank address because it has no choice since no address info is supplied. It would be very useful if you confirm whether that's the case in the situations where it "fails".

(and it always returns the shipping address, it seems)

Yes, that's how PayPal works.

the variable $order is damaged in such a way that ec_step2() cannot populate the order info.

In addition to the comparison of the logs, I think it's crucial that you research *that* more.
The rest of your "fix" is merely a bandage to *that* issue.

[shutterdrone]

Perhaps a comparison between the logs for the failing vs non-failing transactions might be useful?
Namely what is the value returned from PayPal for ADDRESSSTATUS ?
If it's returned as "NONE" then Zen Cart treats it as a blank address because it has no choice since no address info is supplied. It would be very useful if you confirm whether that's the case in the situations where it "fails".

.In addition to the comparison of the logs, I think it's crucial that you research *that* more.
The rest of your "fix" is merely a bandage to *that* issue.

Oh, I absolutely understand that this is just a band-aid. I just ran out of time debugging, as we had just launched the site a few days earlier, and were getting hammered with support issues over paypal.

I'll be digging more into the logs over the next few days, but the only difference I saw up and to that point was that it didn't get blank values for the order variable in before_process() or ec_step2(). Need to add more debugging hooks in there to see what's different, but the paypal CURL initial responses looked the same as when it fails.

Ultimately, I think attempting to load the wordpress modules directly into the zen cart space is a bad, bad idea. It would've been better to use RSS to handle the communication, or some other syndication use.

I'm still confused as to how it could have damaged the $order variable in such a way that ec_step2() cannot even populate it (and why I get no PHP errors concerns me too..), but PHP is not a language I am very familiar with, yet, I just need to hook in a var_dump in there and see what happened to $order. It's a VERY common variable in the wordpress files, and part of the reason I don't think it's a good idea to just go hooking up two pieces of code managed by two different groups blindly.

Ultimately, I'm just going to eliminate the WOZ sidebars with hard-coded or re-coded ones to prevent WOZ from loading the WP files when not needed. It is not necessary to load the WP modules just to get a list of categories or pages as WP provides plenty of ways of querying that information.


I would, however, recommend adding that sanity check to addAddressBookEntry(), considering that it also exists in findMatchingAddressEntry(), and they should probably both ignore invalid input, rather than just one of them.

[DrByte]

Ultimately, I think attempting to load the wordpress modules directly into the zen cart space is a bad, bad idea.

I couldn't agree more.

[shutterdrone]

I couldn't agree more.

Yup, it turns out it breaks all kinds of stuff - like the shipping estimator for guest users, amongst other things.

BTW, the patches above are not a good idea - the ramification was that it sends out an invoice with blank ship to address, and the orders have blank ship to's.

The only real solution was to make it such that it only loaded WOZ when the target was actually a wordpress page (like a previous user indicated), and hand-code the wordpress sidebars, as the WOZ sidebars obviously don't work without loading wordpress code.

Additionally, there are major CSS issues with WOZ, and the module should really be coded to only load _anything_ when wordpress is the target. I had to modify it to stop loading different files when it wasn't necessary before we launched the store to eliminate issues between WP and ZC. We just didn't predict the paypal issues.