USPS Standard Post rates still have malformed output

[JustinSainton]

See screenshot: http://cl.ly/image/2z3M1Y2H1o1I

@ReactorShop - are you seeing similar issues? That screenshot is on a site running the latest master branch.

[ReactorShop]

Once in a while I get the malformed character to the right of the Standard Post service.

As you can see here:

It's not a "consistent" issue, so I can't trace it.

If this issue is "consistent" at that site, I would recommend to dump the USPS response into a file before applying _clean_response to see which specific characters are received.

It could be a case in which USPS send the hexadecimal representation of the registered symbol, instead of its decimal representation.

[JustinSainton]

Interesting - it does seem consistent on that site, which is odd. Seems to just be the "registered" entity being malformed.

It's a concern to me only because I think it might cause the switchmethod() function to not actually work.

[ReactorShop]

@misulicus theorized that this could be related with Windows hosting (my website is hosted on an Apache server).

If this could be the case, USPS might be sending this char differently based on something it detects in the header when getting the rates request.

As I said before, adding a PHP file_put_contents() line at the beginning of the _clean_response method at that server might reveal more.

[ReactorShop]

I was forgetting something.

You might think that this is "consistent" response because you are seeing the same malformed character every time you go into the Checkout page.

But if you're not changing the cart contents, you're seeing the already cached malformed response every time you check the Checkout page.

You need to delete your cart contents and add them again, or modify quantities every time you want to check if the malformed character response is received.

[JustinSainton]

Yep, I changed the cart and ZIP, etc. Same result

[JustinSainton]

Also worth noting, maybe, that the $is_IIS and $is_iis7 globals are returning false.

[ReactorShop]

The fast track path would be to add the file_put_contents($response) line and compare the elements to the right of the "Standard Post" description in it against the str_replace lines located at the _clean_response method.

[JustinSainton]

As a side note (and probably a new ticket) - I am finding scenarios where a shipping method will return options named "0" or "1", with values of $0.00.

[ReactorShop]

That's new for me. I've tested these modules since September-October and never had an occurrence of it.

The services are parsed by this method:

/**
 * Parse the service out of the package
 *
 * @since 2.0
 * @param string $package
 * @return string
 */
function _get_service( $ServiceTag, $package ) {
    global $wpec_ash_xml;
    $service = "";
    $temp_service = $wpec_ash_xml->get( $ServiceTag, $package );

    if ( $temp_service ) {
        $service = $temp_service[0];
    }

    preg_match( '/(.*?)<sup>/', $service, $temp );
    if ( ! empty( $temp ) ) {
        $service = $temp[1];
    }

    return $service;
}

Which uses this shipping helper method:

/**
 * This is a helper function that retrieves an XML element from the
 * provided document. Since we are trying to keep PHP4 support
 * I cannot use simpleXML
 *
 * @since 0.0.1
 * @param string $element  The element to find in document
 * @param string $document The XML Document to search
 */
function get($element, $document){
    preg_match_all('/<'.$element.'.*?>(.*?)<\/'.$element.'>/', $document, $matches);

    if (count($matches) > 1){
        return $matches[1];
    }
    return FALSE;
}

[mihaijoldis]

as @JustinSainton mentioned i have seen users with rates returned as 0 name with price 0 too.

[ReactorShop]

Based on @misulicus comment, this issue has existed before all these modifications, since WPEC 3.8.13 doesn't have them.

I'm currently unable to replicate this issue, so testing will be needed on those sites or their development environments in order to determine what's causing them.

[codysnodgrass]

I'm getting weird characters for my USPS shipping options.

Any ideas on how to fix?

WP e-Commerce Version 3.8.13.3 WP Version 3.8.1

[ReactorShop]

@codysnodgrass, you have to download the 3.8.14 milestoned wpsc-shipping/usps_20.php, wpsc-shipping/ups_20.php and wpsc-includes/shipping.helpper.php files and use them to replace the ones you currently have installed.

This will display the registered symbol as expected, but may increase the shipping rates if using advanced rates, because the correct package dimensions are now taken into consideration to request rates.

[codysnodgrass]

@ReactorShop I'm new to GitHub, where would I download the 3.8.14 milestoned files?

Thanks

[ReactorShop]

@codysnodgrass, the fastest, easier way would be to navigate here:

https://github.com/wp-e-commerce/WP-e-Commerce

and click the "Download ZIP" button found at the bottom of the right column.

Open the ZIP file in your computer and look for the folder/file combinations indicated.

[codysnodgrass]

Thank you! I did that and it helped clean it up, now I have a diamond with a ?.

[ReactorShop]

@codysnodgrass, as I explained a few posts above, neither my website nor my test environment (which currently doesn't work because of unrelated issues) show that specific problem, so I personally can't help with this issue.

I asked @JustinSainton to dump the USPS response to a file before applying _clean_response to see what's causing it.

If you can add a file_put_contents statement before _clean_response is applied and check which specific chars are received in between First-Class Mail and Parcel, that might help to troubleshot this.

[mihaijoldis]

@ReactorShop i got the same weird character after First-Class Mail (CHARACTER) Parcel. I added the file_put contents in the _clean_response before the repalcements:

`<?xml version="1.0" encoding="UTF-8"?>

863363371404REGULARFALSE7First-Class Mail&lt;sup&gt;&#174;&lt;/sup&gt; Parcel2.509Certificate of Mailingtruefalse1.3001Insurancetruefalse2.100truefalse5Registered Mail&lt;sup&gt;&#8482;&lt;/sup&gt;truefalse11.950truefalse4Registered without Insurancetruefalse11.9500Certified Mail&lt;sup&gt;&#174;&lt;/sup&gt;truefalse3.30013USPS Tracking&lt;sup&gt;&#8482;&lt;/sup&gt;truetrue1.050.0015Signature Confirmation&lt;sup&gt;&#8482;&lt;/sup&gt;truetrue2.902.356Collect on Deliverytruefalse6.950truetrue863363371404VARIABLEREGULAR7Priority Mail 2-Day&lt;sup&gt;&#8482;&lt;/sup&gt;6.459Certificate of Mailingtruefalse1.3001Insurancetruetrue2.102.10truefalse5Registered Mail&lt;sup&gt;&#8482;&lt;/sup&gt;truefalse11.950truefalse4Registered without Insurancetruefalse11.9500Certified Mail&lt;sup&gt;&#174;&lt;/sup&gt;truefalse3.30013USPS Tracking&lt;sup&gt;&#8482;&lt;/sup&gt;truetrue0.000.007Return Receipt for Merchandisetruefalse4.40015Signature Confirmation&lt;sup&gt;&#8482;&lt;/sup&gt;truetrue2.902.3519Adult Signature Requiredfalsetrue05.2020Adult Signature Restricted Deliveryfalsetrue05.456Collect on Deliverytruefalse6.950truetrue863363371404VARIABLEREGULAR7Priority Mail Express 1-Day&lt;sup&gt;&#8482;&lt;/sup&gt;29.2511Priority Mail Express Insurancetruetrue1.001.00truefalse8Return Receipttruefalse2.70019Adult Signature Requiredfalsetrue05.2020Adult Signature Restricted Deliveryfalsetrue05.456Collect on Deliverytruefalse6.950truetrue` i think this is the culprit: `First-Class Mail&lt;sup&gt;&#174;&lt;/sup&gt; Parcel` any ideas ?

[JustinSainton]

Looks like part of the bug is the double decoding we're doing -

http://cl.ly/image/1Q1i0M2q1B1r

[ReactorShop]

@JustinSainton is correct. The problem appears after double decoding the string.

What is odd is that I don't get this malformed character in my Apache dev or prod installations.

Since @misulicus has this installed in a Windows server, could this be related to how Apache and Windows differently treat these characters when decoding them?

[JustinSainton]

I think if we replace the html_entity_decode() calls with wp_specialchars_decode(), we can safely double decode without unexpected results.

[ReactorShop]

@misulicus, can you please test using the wp_specialchars_decode() function @JustinSainton recommended?

[mihaijoldis]

Oh forgot to mention sorry. This i just got it from a users website on support. I replaced the usps.php and the helper with the ones from the master as @ReactorShop indicated to fix the weird characters. That worked, and now i`m left with that weird character. Users website is apache: PHP Version 5.3.24

[JustinSainton]

@misulicus @ReactorShop If you guys both want to test 2e9b2aa02f14479b23664193c4690d816f4eba76 to see if it works fine, that'd be great.

[JustinSainton]

Seems to work okay in my testing - http://cl.ly/image/160y3P1t0p3n

[ReactorShop]

@JustinSainton As I indicated before, I don't get this malformed character (see the 2nd post on this thread). That's why I'm asking @misulicus the favor of testing this modification.

[mihaijoldis]

on the users website seems to work: (justins PR) https://dl.dropboxusercontent.com/u/16683640/Screenshots/2014-04-05_2118.png

[JustinSainton]

@ReactorShop Awesome - my hope is that you still won't get the malformed character, and this new approach won't cause any issues with you, or the majority of other users, who also do not get the malformed character.

[JustinSainton]

Going to go ahead and close as fixed - @ReactorShop, let me know if you do end up seeing any regressions.

[ReactorShop]

MySQL doesn't want to start, again!

I'll test after I fix it.

[JustinSainton]

Sounds like it's time for you to give Vagrant a try :)

[ReactorShop]

What I like about using Macs, is that I could easily set up multiple virtual hosts on my development environment in a native manner. I didn't like MAMP because it's separate from the development computer, but now I see that once in a while a Mac update can mess my setup.

I'll need to go through the Vagrant documentation to know what do I have to trade off.

[JustinSainton]

Take a look at VVV.

I think you'll fall in love.