USPS Shipping (RESTful) (USPSr)

[retched]

As stated, all items installed are latest GitHub versions.

PM with log sent.

Hi your PMs are being blocked as I tried to send it. You can link a private pastebin or send to my hotmail.com (yes I'm old) email address with the same username.

[retched]

Have you installed the latest released USPS-r? I thought this was fixed.

I'm 90% sure I know what the problem is and it's something that I didn't think WOULD be a problem.

[dbltoe]

Using the estimator on the shopping cart.

Estimate time to No in Restful

Zip + 4 used.

I get the expected two options with the cheapest highlighted.

Continuing to OPC using Zip + 4

after adding data for guest, I am presented with the two shipping options with the more expensive priority selected.
The order processed and returned with the Zip + 4 and (NEW) the fee charged was for the cheaper ground although priority was checked on the confirmation page.

[retched]

Using the estimator on the shopping cart.

Estimate time to No in Restful

Zip + 4 used.

I get the expected two options with the cheapest highlighted.

Okay I thought so. For clarity: dbltoe sent me their log and as part of the log I noticed the "standards" request was being bounced and causing errors.

For some reason, the USPS thought it was OK to allow the ZipCode to be hyphenated in cost quotes request but NOT be hyphenated in the "standards" (aka time estimates) request. This is weird and something I have no control over as it's on the USPS' side as to how the API request is handled. I'm going to have the module chop off the back four and use only the front five digits of the Zip code quote making or time estimates.

Continuing to OPC using Zip + 4

after adding data for guest, I am presented with the two shipping options with the more expensive priority selected.

I still do not know WHY the more expensive option is being selected by default. I've tested this on my own test box, and if I remove all other shipping methods besides USPS, it defaults to the most expensive USPS option. I do not know why that is.

The order processed and returned with the Zip + 4 and (NEW) the fee charged was for the cheaper ground although priority was checked on the confirmation page.

And now I need to start investigating why the wrong option was used during OPC checkout. (I'm 90% sure it has to do with the "value" attribute of the radio button.) Trying to fix both of these now.

[retched]

Tl;dr: I figured out what went wrong with, everything here. A bugfix will be submitted shortly.

Okay I thought so. For clarity: dbltoe sent me their log and as part of the log I noticed the "standards" request was being bounced and causing errors.

For some reason, the USPS thought it was OK to allow the ZipCode to be hyphenated in cost quotes request but NOT be hyphenated in the "standards" (aka time estimates) request. This is weird and something I have no control over as it's on the USPS' side as to how the API request is handled. I'm going to have the module chop off the back four and use only the front five digits of the Zip code quote making or time estimates.

Really annoying bug or limitation of the API. It accepts 00000-1234 for quotes but will break when it tries to make standards quote requests (aka how many days does this method take) which must be either 000001234 or 00000. The fix is to nix the Plus 4 from the submission and instead basing it solely on the Zip Code (the five digits). Nobody has to change anything, the zipcode will be dispatched as five digits. (AKA if your customer puts in 00000-1234, the order will process as 00000 but will be inserted into the order as 00000-1234.)

I still do not know WHY the more expensive option is being selected by default. I've tested this on my own test box, and if I remove all other shipping methods besides USPS, it defaults to the most expensive USPS option. I do not know why that is.

And now I need to start investigating why the wrong option was used during OPC checkout. (I'm 90% sure it has to do with the "value" attribute of the radio button.) Trying to fix both of these now.

I know why. I thought I was being smart trying to not "waste" indices of a loop and only counting what was used. This was bad. OPC and ZenCart's shipping estimator used those ID's and it backfired as it considered ALL of the methods the "cheapest" as they all were sent out as "usps_usps0". Moved the logic of the index count to a more sensible location.

Each of these fixes are ready to be deployed in version v1.1.1. Which will be published shortly. Just waiting to make sure that no other problems arise. (My apologies, this is possibly the biggest contribution I've done to date.)

[retched]

Pending updates v1.1.1 has been submitted to the Module Directory and published to the GitHub.

https://github.com/retched/ZC-USPSRe...ses/tag/v1.1.1

What's changed?

Fixed

• Resolved all issues with regards to the selection of shipping methods during checkout. (Issues #28, #29, #30, #31) (Long and short run, there was a problem with the counting of each module presented and it caused issues.)
• Fixed an issue that came up when trying to squash options but you were also using estimated dates/times (the squashing was ignored and all options were presented anyway, bad regex matching). (Issue #32)

[swguy]

This looks like something you are already investigating, just passing on a simpler report. Select more than one method in USPS-r's admin configuration. Go to standard checkout and you see one radio button per method. However, all have the value of ship-uspsr-usps0 as noted. I thought it would be a simple matter of only initializing the counter ($m) at the start of the outer loop, but it still selected the first method (the most expensive) on the payment page, no matter which I selected on the shipping page.

[swguy]

Just downloaded 1.1.1. I think you still have an indexing issue. It still always shows the first method (Priority Mail) as the selected one on the second page of checkout.

Also you might want to think about how you handle the checkout pages after initial selection. You'll notice the other shipping modules use the signature

function quote($method = '')

where the selected method is passed in after the first call.

[swguy]

If this helps, the quote method is called with an argument -see includes/classes/shipping.php line 257

[retched]

This looks like something you are already investigating, just passing on a simpler report. Select more than one method in USPS-r's admin configuration. Go to standard checkout and you see one radio button per method. However, all have the value of ship-uspsr-usps0 as noted. I thought it would be a simple matter of only initializing the counter ($m) at the start of the outer loop, but it still selected the first method (the most expensive) on the payment page, no matter which I selected on the shipping page.

Ugh I thought I tackled this. It's showing up as working on my end... Unless I packed the wrong files which is strongly possible...