USPS shipping quotes contain double encoded html

I'm hoping this is just a temporary situation and will be fixed shortly on the USPS end. I for one plan on calling them tomorrow and discuss this change with them - it is unquestionably wrong of them to put doubly-encoded HTML into their XML return strings. Anyway, let's leave this open so that people who need the fix will be able to find this patch, but I suspect it won't have to be committed.

Awesome, thanks! (Just to clarify, without this patch, does anything broke? In other words are shipping quotes not returning anything without this patch?)

USPS Shipping quotes still work, but the names of each service (e.g. USPS Priority Mail) have a whole bunch of ugly encoded HTML displayed as a suffix.

Oh, alright. I haven't had anyone email us with issues (yet), and the patch applied cleanly, so thanks.

Thanks for the zippy patch

Mixologic, how are you able to send a quote with no zipcode? Unless I'm missing something, I thought Ubercart required the zipcode before sending the request to the quote providers?

Subscribing and hoping USPS will amend their API!

Thanks for the patch.

Subscribing!
Thanx for the patch. Hopefully they will fix the API.
woof

@Mixologic

I noticed that the patch does a string replace, it would be nice if you used the htmlspecialchars_decode() so that any future changes in the HTML would be handled by this function.

For example

$services[$attr['classid']]['label'] = t('U.S.P.S. @service', array('@service' => htmlspecialchars_decode($postage->mailservice[0]->data())));

I would have posted the patch, but I am working on the Drupal5 version of Ubercart in my client website.

Regards
Santhosh Raju

@Mixlogic,

Hello, thank you for providing the code. This does help remove the unwanted letters displaying to customer.

Have you noticed anything with the First class? I am trying to check the rates for a 5 oz envelope regtangular. But all i get is Priority Shipping, Flat Rate Priority Shipping, and first class postcard shipping. The rates are crazy for postcard first class so it doesn't give the right amount. Did USPS made any changes that affects the first class option?

I couldn't find a thread where to put this, so I hope it is ok.

Thank you for your hard work!

David

Subscribing

I think the issue with first class isn't about the rates, but it's that a quote for first class shipping isn't being displayed at all. At least that's what I'm (not) seeing. Products that used to have a first class shipping option don't currently have that option displayed.

I think I see why the first class shipping options aren't being displayed. In uc_usps.module lines 393 and 396 a string comparison is being made to set the class ID:

              if ($classid === '0') {
                if ((string)$postage->MailService == "First-Class Mail Parcel") {
                  $classid = 'zeroParcel';
                }
                elseif ((string)$postage->MailService == "First-Class Mail Flat") {
                  $classid = 'zeroFlat';
                }
                else {
                  $classid = 'zero';
                }
              }

That might not work as expected when the strings returned from the USPS look like this:

<Postage CLASSID="0">
  <MailService>First-Class Mail&lt;sup&gt;&amp;reg;&lt;/sup&gt; Package</MailService> 
  <Rate>1.22</Rate> 
</Postage>
<Postage CLASSID="0">
  <MailService>First-Class Mail&lt;sup&gt;&amp;reg;&lt;/sup&gt; Large Envelope</MailService> 
  <Rate>1.22</Rate> 
</Postage>
<Postage CLASSID="0">
  <MailService>First-Class Mail&lt;sup&gt;&amp;reg;&lt;/sup&gt; Letter</MailService> 
  <Rate>0.64</Rate> 
</Postage>
<Postage CLASSID="0">
  <MailService>First-Class Mail&lt;sup&gt;&amp;reg;&lt;/sup&gt; Postcards</MailService> 
  <Rate>0.28</Rate> 
</Postage>

Fixed the lost ability to calculate First Class Package rates by changing line 393 of uc_usps.module

if ((string)$postage->MailService == "First-Class Mail Parcel") {

changed to:

if ((string)$postage->MailService == "First-Class Mail^® Package") {

@Sah62,

Yes that is what I was trying to say. I was getting only post cards and not the first class actual rates. I kind of fixed it by putting a temporary flat rate for anything less than 13 onces at 3.50 which was a bit reasonable. Though I would love to get the actual rates like before.

Hope wkeef's fix does help give us a the first class quote back again.

Thank you for all your support guys,

David

I crafted a temporary fix until Ubercart is patched. Issues I found were:

1. FirstClass service name changed from "First-Class Mail Parcel" to "First-Class Mail Package".
2. Extra '*' appended on some international service names.
3. Returned XML contains double-encoded HTML.
4. Residual XML tags in service name data.

The fix is based on the 1.x uc_usps.module code. How to fix:

(1) Open uc_usps.module.

(2) Add the following function to the bottom of the file:

/**
 * Cleans up USPS' new XML, name changes, etc (released 1/2/2011)
 * JSR [01/08/2011] Verbose to be clear what is going on.
 */
function _uc_usps_fixquote($quotedata) {
	$decodeddata = htmlspecialchars_decode($quotedata);	//Decode special characters
	$cleandata = $decodeddata;							//Default
	$startpos = strpos($decodeddata, '<', 0);			//Search for pos of '<'
	if($startpos !== FALSE){							//Did we find a start of a tag? If not, don't mess with string.
		$endpos = strrpos($decodeddata, '>', 0);		//Seach for pos of last '>'.
		if($endpos !== FALSE && $endpos < strlen($decodeddata)){//Did we find end tag? If not, don't mess with string.
			$cleandata = substr($decodeddata, 0, $startpos);//remove tags and everything between.
			$cleandata .= substr($decodeddata, $endpos+1);
		}
	}
	
	//Special case: Some international service names have '*' on them.
	$cleandata = str_replace("*", "", $cleandata);
	
	return $cleandata;
}

(3) Fix broken condition for Firstclass domestic in uc_usps_quote() around line 306.

Search for: if ($postage->mailservice[0]->data() == "First-Class Mail Parcel")

Replace with: if (_uc_usps_fixquote($postage->mailservice[0]->data()) == "First-Class Mail Package")

(4) Fix domestic service names in uc_usps_quote() around line 316.

Search for: t('U.S.P.S. @service', array('@service' => $postage->mailservice[0]->data()));

Replace with: t('U.S.P.S. @service', array('@service' => _uc_usps_fixquote($postage->mailservice[0]->data())));

(5) Fix international service names in uc_usps_intl_quote() around line 423.

Search for: t('USPS @service', array('@service' => $service->svcdescription[0]->data()));

Replace with: t('USPS @service', array('@service' => _uc_usps_fixquote($service->svcdescription[0]->data())));

That's it. Tested and currently being used on a live site. Let me know if you find any issues I overlooked.

Jeff

I'm using uc_usps.module,v 1.6.2.22 which looks a little different than the code above e.g. (5) above is on line 385 and looks like this:
(t('U.S.P.S. @service', array('@service' => (string)$service->SvcDescription));

Anyway... I tried the fixquote wrap but it didn't work. Let me qualify that... I think I'm having problems with the USPS module but it's not the same problem... I'm simply not getting any quotes from the quote module. Any suggestions?

1.6.2.22 seems to be the most up to date and stable, so I hope labtech will look at that, as it looks waaaay off from the search and replaces listed... in all three extra examples after pasting at bottom. Thank you for your fix but again, we are all on 1.6.2.22.

nor is the same in dev version 1.6.2.24

It would seem that pretty much all services EXCEPT first class work (including oddities like library mail and media mail) Although for 99% of my clients first-class is what is dearly NEEDED.

Re jhenry13:I'm using uc_usps.module,v 1.6.2.22 which looks a little different than the code above e.g. (5) above is on line 385 and looks like this:
(t('U.S.P.S. @service', array('@service' => (string)$service->SvcDescription));

This works fine for me using:
t('U.S.P.S. @service', array('@service' => _uc_usps_fixquote((string)$service->SvcDescription)));

Labtech's function works fine for me to clean it up and get the shipping working in general, however I believe there is more to this if the store needs to fully support the admin options of the various enabled shipping choices for USPS. I was not able to look into it with great detail, but it seemed during my testing that (for example), the Postcard shipping option was being considered as First Class Package mail, and clearly at some point, the module will need to display the appropriate markup, and not strip this out.

You can pretty much follow labtech's steps with 1.6.2.22, just slightly different line numbers and code in question.
$services[$id]['label'] = t('U.S.P.S. @service', array('@service' => (string)$service->SvcDescription));
Becomes:
$services[$id]['label'] = t('U.S.P.S. @service', array('@service' => _uc_usps_fixquote((string)$service->SvcDescription)));
---
if ((string)$postage->MailService == "First-Class Mail Parcel") {
Becomes:
if (_uc_usps_fixquote((string)$postage->MailService) == "First-Class Mail Package") {

---
elseif ((string)$postage->MailService == "First-Class Mail Flat") {
Becomes:
elseif (_uc_usps_fixquote((string)$postage->MailService) == "First-Class Mail Flat") {
---
$services[$classid]['label'] = t('U.S.P.S. @service', array('@service' => (string)$postage->MailService));
Becomes:
$services[$classid]['label'] = t('U.S.P.S. @service', array('@service' => _uc_usps_fixquote((string)$postage->MailService)));
---

Subscribing

This works like a charm for the stable version, now I need to get rid of the "postcard" shipping that USPS seems to be forcing down my clients neck. As soon as I figure that out I will use the same type of temp fix and post it here in a patch.

Thanks. Post #24 worked for me on the lates module.

Hi,
Thanks for providing this. #19 and #24 for the latest version fixed this for me as well. Sounds like USPS shipping quote return format needs to be monitored on a regular basis if you have this in production.

#19 + #24 works for me too.

I've spent several hours on the phone with USPS over the past three weeks, and I have exchanged several e-mails with them. Here's my understanding of the current situation:

1) On 2 Jan, RateV4 was introduced and RateV3 was deprecated.
2) RateV4 documentation was *not* available officially until 7 Jan. They don't see a problem with that.
3) RateV3 requests will still work, however RateV3 had some changes that went into effect on 2 Jan. These changes were not announced ahead of time (or after the fact, for that matter). They don't see a problem with that.
4) These RateV3 changes are *not* documented - there will be *no* update to the RateV3 documentation last published in Jan 2010. Again, they don't see a problem with that.
5) The double-encoded HTML has been fixed, it's now just single-encoded. But it's going to remain that way.

So, what does this imply for Ubercart? Let me address some of the comments in this issue:

@Mixologic #6: Those error tags are actually correct according to the old RateV3 documentation as of Jan 2010. Yes, it's inconsistent, but does comply with their documentation. I haven't looked to see if Ubercart properly handles error returns in both cases - this is something that could have changed since the uc_usps module was first written.

Re: "patch" #19/#24 - The problem with this approach is that the USPS terms of use for their API now requires the trademark symbols to be displayed as part of the service name. Stripping them out entirely is not an option. (I'm switching this back to "needs work" for that reason.)

What I feel is the best thing to do is to convert the HTML markup returned by USPS as part of the service name into actual characters - i.e. replace <sup>®</sup> by ® and '<sup>™</sup> by ™. IMO, USPS should be returning these characters directly anyway, instead of HTML markup. (XML standards demand implementations handle UTF-8 and UTF-16 character encodings properly, thus the contents of XML strings are not limited to the ASCII character set - in particular ® and ™are perfectly valid characters in this context and do not need to be replaced by HTML markup.) If this substitution is made on the $response object *before* any processing, then very little else will need to be done (the * should be stripped from the International service names at this same point). In fact, I think just adding the ® or ™to the string literal service names that Ubercart uses should suffice. This way, we don't have to keep running a "fixquote" function every single time we want to actually *use* the name. Likewise, this way we avoid situations like @Mixologic mentioned in #14.

This substitution needs to be done with both RateV3 and RateV4. Ubercart eventually has to move to RateV4, but this will require some real work to go over the new spec and rework all the old Ubercart code to conform to the new API. I don't have time to volunteer for that at the moment. Please discuss the conversion to RateV4 in the issue created for that purpose: #985450: Migrate USPS module to RateV4

Also looks like we might need to add a hook_update() to change the service names stored in the DB.

Subscribing... customers are not happy that first class is no longer working :( Will try 19+24.

edit: looks like I'm not even getting first class in my response... not sure why.
double edit: it's working now

#33

Do you know what you did to get First Class working?

I.E. Run cron or update.php

Hi:

I'm having this exact same problem... The whole first class thing is a major problem for me cause it's not just domestic but international.

I've messed with cutting and pasting a variety of the solutions above, but with not luck. My module is 1.6.2.11

I'm not a real coder. Does someone have a compatible updated module or can I pay someone to fix mine???

I'm in deep water with this not working.

Quint

UPDATE: I'm pleased to report that I did the end of file stuff in #19 and then #24 and it seems to be working OK. I need to check international, but domestic is working.

Domestic seems to be working... International is kind of working... It is returning CRAZY Priority Mail rates... Like $25 for 4 oz to England????

@qrandle: $25 is LOW, unless you're using a flat rate envelope ...

See http://ircalc.usps.gov/MailServices.aspx?country=10150&m=6&p=0&o=4

Due to this and the other general issues with USPS, should it be dropped and moved to contrib before the 7.x-3.0 release of Ubercart?

How can I apply the patch without shell access? i.e. shared hosting?

If you have FTP access you could apply it manually. (Basically means copying and pasting, and removing the - and + signs from it. How-to page is here: http://drupal.org/node/534548

subscribing

2.4_ubercart_usps.patch worked for me

hi,

For those that don't like patching, if its just for the display you can also use code in a custom module like this:

/**
 * Implementation of hook_theme_registry_alter().
 */
function mymodule_theme_registry_alter(&$theme_registry) {
  if (!empty($theme_registry['uc_usps_option_label'])) {
    $theme_registry['uc_usps_option_label']['function'] = 'mymodule_uc_usps_option_label';
  }
}

/**
 * Override:
 *
 * Theme function to format the USPS service name and rate amount line-item
 * shown to the customer.
 */
function mymodule_uc_usps_option_label($service) {

  // Clean service (as of changes from USPS from Jan 10, 2011)
  $service = str_replace('&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt;', '<sup>&trade;</sup>', $service);
  $output = $service;

  if (function_exists('theme_uc_usps_option_label')) {
    $output = theme_uc_usps_option_label($service);
  }

  return $output;
}

Remember to clear theme cache afterwards.

Best Wishes,

Fabian

By the way the 2.4 patch (from the original post) seemed to work fine for me, logos are appearing and I'm getting First Class quotes.

What are the next steps? As TR pointed out, the solutions presented here are not the be-all, end-all. Although I am almost convinced that this issue, being that it's not a show-stopper (assuming everyone has First Class quotes coming back) should be ignored in favor of #985450: Migrate USPS module to RateV4 as the better solution

Personally, I don't mind "not conforming" to their spec as long as the results are what we expect - that is, working quotes and logos. Thoughts? Are others able to successfully get quotes returned? @redhatmatt, I'd be interested to know if this is still an issue for you.

I'm just using Mixologic's original patch (except like him, stripping out the ® and ™ altogether).

So far so good.

This may sound silly... but I realized after patching the reason First Class wasn't working for me is because first class has a weight limit of 13oz!

The product I had in my cart was 14oz... so USPS did not return First Class. So the patch 19+24 works just fine, but don't be silly like me and think it's not because your items are over 13oz.

@#44: That's not the best workaround, as TR mentioned in #30 since it doesn't adhere to the USPS API guidelines. So I think we are waiting on a new patch, if I'm not mistaken?

subscribing

Alright... not much of a patch - just adding in the str_replace() calls but

- working them during processing of the $response object as suggested in #30

- unlike suggested in #30, I could not get ® and ™ to render, so it uses entities ™

- I did not add the ® or ™to the string literal service names that Ubercart uses, but it seems to work so far except that, of course, the ® and ™ are missing in the admin interface.

Patched against UC 2.4.

Seems to work for me so far on a testbed.

Nice! Setting to needs review, since there's a new patch.

Untested, as I don't use USPS, but instead of duplicating code it would be better to introduce a uc_usps_clean_service_name() function or similar, with a comment as to why this is needed, as it's not immediately obvious. Also note that you don't need to call str_replace() multiple times, it can accept arrays when replacing multiple strings.

This is perhaps outside the scope of this issue, but I'm also not sure that t() should be used here, as I don't see why you would translate this - USPS is an acronym you probably shouldn't change - and theme_uc_usps_option_label() makes an assumption about the first 9 characters which may not be true if the string was translated.

I wonder if it's also worth using html_entity_decode() (twice?!) instead of str_replace() in case USPS decide to break their service again in weird and wonderful ways?

Thanks longwave!

I think you'll find this cleaner. Note that the patch includes *both* of your suggestions (arrays in str_replace and html_entities_decode), with the second one commented out. I thought that will make it easy for people to apply the patch and test both. So obviously, this is a preliminary patch in any case. I'm happy to roll final patch either way, or yet a third way if someone has a better solution. In my testing, both solutions work perfectly, so if anyone else feels like testing, it would at least be a short-term fix.

I originally thought about html_entity_decode() but since I don't know the API, I was afraid that it might break something else. It could be done that way simply enough. I tested it as

$services[$classid]['label'] = html_entity_decode(html_entity_decode(t('U.S.P.S. @service', array('@service' => (string)$postage->MailService)), ENT_NOQUOTES), ENT_NOQUOTES);

This works fine in my tests. I thought leaving double encoded quotes alone was better than accidentally decoding quotes that should stay encoded, so thus ENT_NOQUOTES flag.

On the plus side, it doesn't add any lines of code. On the downside, I don't know whether or not it might breaks something downstream. Just for kicks, I tested *three* nested calls to html_entity_decode() and that results in invalidly encoded characters. So if despite assurances to TR, the USPS were to change their encoding, that would break.

I like that the str_replace() solution is very specific and, for example, if USPS did change the encoding, it wouldn't break something, it would just do nothing because it wouldn't match.

Realistically, either solutions is quite ugly and, I think, just a stopgap until a RevV4 solution comes online (if people say otherwise, I'm happy to wrap a new patch).

As for the t() - that's in the distro and I'd rather make as few changes to the distro as possible.

html_entity_decode($string, ENT_COMPAT, 'UTF-8'); should decode the characters correctly - but as you say this is a stopgap and USPS (probably) won't break it again until RateV4 needs to be implemented, so your patch will likely be enough until then.

TR: do you use USPS? Or can someone else who uses it test this? Is comment #6 an issue? What about the first class problems noted above?

Longwave,

If I send a request without a zip, I just get a very nice

"There were problems getting a shipping quote. Please verify the delivery and product information and try again. If this does not resolve the issue, please call in to complete your order."

I can't turn on the First Class at the moment - this is a testbed, but a client is using the testbed to experiment with product weights and shipping costs and doesn't want to see First Class. If nobody else wants to test/patch, though, I can tell him what I'm doing and let it show First class for a while.

Got a question. For background, I'm a software developer, but not particularly knowledgeable about the Drupal innards. I'm just setting up a website using Ubercart and USPS shipping options. I applied the patches given by Mixologic at the top of this thread and by Ergophobe posted on February 9. The first of these fixed the shipping options display, but I have another problem that I'm not sure if anyone here mentioned. In the "Calculate Shipping Cost" box, ABOVE the shipping options, I'm seeing snippets of XML rendered on the page, specifically this rather long and messy . . . well, mess:

API=RateV3&XML=<RateV3Request USERID="986ONEVO0741"><Package ID="0"><Service>ALL</Service><ZipOrigination>21221</ZipOrigination><ZipDestination>21221</ZipDestination><Pounds>1</Pounds><Ounces>0.0</Ounces><Container>RECTANGULAR</Container><Size>REGULAR</Size><Machinable>False</Machinable></Package></RateV3Request>

<?xml version="1.0"?>
<RateV3Response><Package ID="0"><ZipOrigination>21221</ZipOrigination><ZipDestination>21221</ZipDestination><Pounds>1</Pounds><Ounces>0.0</Ounces><Container>RECTANGULAR</Container><Size>REGULAR</Size><Machinable>FALSE</Machinable><Zone>1</Zone><Postage CLASSID="3"><MailService>Express Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt;</MailService><Rate>15.25</Rate></Postage><Postage CLASSID="2"><MailService>Express Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Hold For Pickup</MailService><Rate>15.25</Rate></Postage><Postage CLASSID="23"><MailService>Express Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Sunday/Holiday Delivery</MailService><Rate>27.75</Rate></Postage><Postage CLASSID="13"><MailService>Express Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Flat Rate Envelope</MailService><Rate>18.30</Rate></Postage><Postage CLASSID="27"><MailService>Express Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Flat Rate Envelope Hold For Pickup</MailService><Rate>18.30</Rate></Postage><Postage CLASSID="25"><MailService>Express Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Sunday/Holiday Delivery Flat Rate Envelope</MailService><Rate>30.80</Rate></Postage><Postage CLASSID="30"><MailService>Express Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Legal Flat Rate Envelope</MailService><Rate>18.30</Rate></Postage><Postage CLASSID="31"><MailService>Express Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Legal Flat Rate Envelope Hold For Pickup</MailService><Rate>18.30</Rate></Postage><Postage CLASSID="32"><MailService>Express Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Sunday/Holiday Delivery Legal Flat Rate Envelope</MailService><Rate>30.80</Rate></Postage><Postage CLASSID="1"><MailService>Priority Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt;</MailService><Rate>5.10</Rate></Postage><Postage CLASSID="22"><MailService>Priority Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Large Flat Rate Box</MailService><Rate>14.95</Rate></Postage><Postage CLASSID="17"><MailService>Priority Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Medium Flat Rate Box</MailService><Rate>10.95</Rate></Postage><Postage CLASSID="28"><MailService>Priority Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Small Flat Rate Box</MailService><Rate>5.20</Rate></Postage><Postage CLASSID="16"><MailService>Priority Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Flat Rate Envelope</MailService><Rate>4.95</Rate></Postage><Postage CLASSID="44"><MailService>Priority Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Legal Flat Rate Envelope</MailService><Rate>4.95</Rate></Postage><Postage CLASSID="29"><MailService>Priority Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Padded Flat Rate Envelope</MailService><Rate>4.95</Rate></Postage><Postage CLASSID="38"><MailService>Priority Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Gift Card Flat Rate Envelope</MailService><Rate>4.95</Rate></Postage><Postage CLASSID="42"><MailService>Priority Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Small Flat Rate Envelope</MailService><Rate>4.95</Rate></Postage><Postage CLASSID="40"><MailService>Priority Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt; Window Flat Rate Envelope</MailService><Rate>4.95</Rate></Postage><Postage CLASSID="4"><MailService>Parcel Post&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt;</MailService><Rate>4.90</Rate></Postage><Postage CLASSID="6"><MailService>Media Mail&amp;lt;sup&amp;gt;&amp;amp;reg;&amp;lt;/sup&amp;gt;</MailService><Rate>2.38</Rate></Postage><Postage CLASSID="7"><MailService>Library Mail</MailService><Rate>2.26</Rate></Postage></Package></RateV3Response>

Is anyone else seeing this? And if so, has a patch been developed yet to get rid of it? Thanks!

@lehket: Turn off the debug option at admin/store/settings/quotes/edit - has nothing to do with this issue.

TR,

Oh . . . duh. Thanks! I'm relieved it was something so simple.

So lekhet, did you try my second patch (#52) that incorporates the changes suggested by longwave?

Mixologic's patch and my first patch are definitely not going to get committed to CVS, so it would be great if someone would test my second patch and at least establish some criteria for moving forward.

#52 won't do because it simply translates encoded HTML into HTML. HTML is not appropriate in the service name strings.

I rolled a patch to do what I described in the last half of my post #30, but I haven't tested it with First Class yet - I want to do that before I post it here.

TR - if you post the patch, I'll test it on my sandbox install - wouldn't do any harm if it brought down the whole site in this case, so I don't mind if it isn't fully tested.

For some reason, when I tried to do as you describe in #30, I ran into various character encoding issues, which is why I want back to encoded entities.

Subscribed

#24 worked for me! Thanks so much!

Subscribing.

me too

I have a silly question (sorry if this has already been answered): How come this doesn't work with the T-String Override module? If I enter, exactly, Parcel Post<sup>®</sup> for a T-String, it won't override it. The obvious problem may be that this is not a T-String to begin with, ha! So in this case, can we convert it to a T-String?

Sorry if this is a dumb question.

I'm going to work on this ...

Here's a patch implementing what I suggested in #30. This has been working fine for me for a while. I would appreciate some tests from others to make sure I haven't missed anything. Already committed this to Ubercart 7.x-3.x.

Per my comments in 16 above, the service names returned from the USPS include the words "Large Envelope", "Letter", and "Postcards", none of which will match the comparison for "Flat". Shouldn't the patch either map those services to "Flat" or change the comparison to look for "Large Envelope", "Letter", and "Postcards" instead of "Flat"?

Try this new patch. Part of the problem is that USPS introduced new services at the same time it added the double-encoded HTML to the service names. I would like to confine this issue to dealing with the markup, without breaking existing functionality. So I've changed "Flat" to map into "Letter", so you will be able to continue to get Letter or Parcel quotes for packages and Letter or Postcard quotes for envelopes. But this patch makes no attempt to add new options to deal with the new services - that will have to be a separate feature request.

Tagging.

Patch in #69 works for me on 2.4

Let's see if we can coax the test bot into working here ...

#69: markup3.patch queued for re-testing.

#67: markup.patch queued for re-testing.

(Trying to get the testbot working for Ubercart patches ...)

Looks like we need to fix all those notices in D6 before testbot results are useful - unfortunately there's too many exceptions to be able to see the failures.

@longwave: There're still a few issues with the bot, but at least now the patches are applying and it's trying to run them. I'm working right now on correcting the notices that are triggered by the tests. It'll probably take me a few iterations to get them down to a manageable number. I'm more concerned with the D7 tests anyway - we'll have to see how the bot does with those.

#69: markup3.patch queued for re-testing.

Let's see how the bot does now that >98% of the exceptions have been squashed. "Previous test was 1,010 pass(es), 8 fail(s), and 1,352 exception(es)." (exceptiones? Huh?)

Committed the patch in #69.

I am still having trouble with this.

I have tried the patch here and when that failed, I tried the latest version of uc_usps via the development branch. I am still getting the double encoded HTML. Is there something I am missing or not doing correctly?

I just ran into this today, also, and the patch at #69 worked for me. the only thing that seemed odd to this amateur was that I ran it through terminal and it seemed to need the whole 'shipping' directory present to execute, but then the changed file got dumped on my desktop (the location I ran the patch from)...once I realized the original in the directory hadn't been replaced, I was fine. If the patch runs successfully, there should be a .orig version of the file (uc_usps.module.orig in this case) in the directory also, and the uc_usps.module file in that same location is the updated one. Maybe that's totally elementary, but I'm just learning how to run patches and once I realized that, the patched file fixed the string problem.

thanks for the patch! leave it to the government to go 4 months without fixing a blatant error...

Yes I am quite familiar with applying patches as I have experience testing and writing them myself, for Drupal and other projects. We are just having trouble with this particular patch. We are currently testing the patch against a fresh install to see if we can isolate the issue.

Patch in #69 works for me on two separate sites running UC 2.4. thanks, TR

Seems like USPS changed the codes again (though perhaps it's just me, or the weather).

Had to change

if ((string)$postage->MailService == "First-Class Mail® Package") {

To:

if ((string)$postage->MailService == "First-Class Mail® Parcel") {

Also, it looks like the latest patches are both non-applicable now:

Summary
FAILED: [[SimpleTest]]: [MySQL] Unable to apply patch dev_ubercart_usps.patch. @reason.

Perhaps someone can update the code as per #87, and fix the patch status issue as well?

I just started seeing the double-encoded html in these USPS service labels again. It looks like the api changed the encoding for 'TM' and 'R' symbols. The attached patch adds the new encodings to the current string replacements.

@trrroy: Please post your patch in #2047795: Important USPS Updates - the symptoms are the same but this is new problem and you're posting in a two year old fixed issue.

ok. I posted it on #2047795: Important USPS Updates. Google ranks this page higher ;)

Thanks!