Shipping table pulling billing zipcodes, not shipping zipcode

Hey there!

For some reason, the shipping table seems to be using the billing zipcode as the lookup, not the shipping zipcode

I tested this on my own site, to see if I could replicate it. Here’s what it looks like

* One shipping zone with zipcode 11111 and a flat rate shipping method. >
* One shipping zone with zipcode 22222 and no shipping method

Here’s how I tested at checkout:

1. Set the billing address to use zipcode 11111 > the flat rate shipping option is shown
2. Enabled “ship to a different address” and used the zipcode 22222 > the flat rate shipping is still shown, rather than no rates
3. Refreshed the page > no shipping rates are shown
4. Try changing the zipcodes again > now everything updates correctly

So it seems to take a page refresh to correctly update the shipping based on the new shipping address – this can happen due to caching at server level, as I’ve also seen this when testing different tax rates. Can you test that out on your end and see if it’s the case?

Hi there Hannah,

Thanks so much for your response. I appreciate you looking into this.

Just ran the test you asked me to do 3 times (just to make sure there’s no pilot error!) and the shipping options are not updating.

What I did notice, however, is that upon refreshing, the shipping zipcode field is being overwritten by the billing zipcode field.

What do you make of that?

Many thanks again for your help,

Mike

Hey there,

> What I did notice, however, is that upon refreshing, the shipping zipcode field is being overwritten by the billing zipcode field.

That’s definitely interesting and might start to explain why this shipping is based on the billing address rather than the shipping address.

I can’t reproduce this behavior on my end, so I’m thinking it’s likely a conflict. My first thought is a front-end issue, so you could check the console for potential issues:

Using Your Browser to Diagnose JavaScript Errors

If you don’t find anything relevant in the console, the next step is a conflict test. The best way to determine this is to:

• Temporarily switch your theme to Storefront
• Disable all plugins except for WooCommerce
• Repeat the action that is causing the problem

If you’re not seeing the same problem after completing the conflict test, then you know the problem was with the plugins and/or theme you deactivated. To figure out which plugin is causing the problem, reactivate your other plugins one by one, testing after each, until you find the one causing conflict. You can find a more detailed explanation on how to do a conflict test here.

It sounds like a staging site would be a good idea. If your host doesn’t offer that option, we recommend WP Staging for quickly spinning up a new test site.

Hi again Hannah,

Thank you so much again for your assistance. I fiddled and poked around and found the cause of the problem.

I’ve really screwed about a lot with checkout to get it to flow the way I want(ish). Once of things that I forgot that I had done was created a code snippet to hide the ‘ship to a different address’ field – that’s what was causing the issue all along.

Thank you thank you!

Mike

Hey there,

Thanks for coming back and letting us know what the solution was – I’m glad to hear that you solved it!