Shipping Zones to ship with 2.6

Currently when shipping goods with WooCommerce you can use one of the core shipping methods (flat rate, international, local pickup).

Each method can be used once, and availability is configured per shipping method. Whilst this system is simple, it is in no way flexible for more advanced shipping setups, forcing you to find additional extensions.

Imagine being able to define multiple regions/countries/zip codes and then being able to add as many rates, flat rates, table rates, free shipping methods, etc as you want to each. Sounds good right? Enter shipping zones.

What are Shipping Zones?

Shipping Zones are groups of locations to which you ship products. You can group multiple continents, countries, states, and zip codes into a ‘zone’ for example you could have:

  • Local Zone = California ZIP 90210
  • US Domestic = All US states
  • Europe

Then each one of these zones can contain multiple shipping methods, such as free shipping, local pickup, and flat rates. Customers within the zone only see the shipping methods applicable to them.

Here is a demo showing zone setup:

The customer, after inputting their address or being geolocated, would be matched to one of these zones and be offered the appropriate rate. Magic!

What about the old shipping methods and existing stores?

If already enabled, the old CORE shipping methods will continue to function as-is until disabled. They will be named ‘legacy’ methods for backwards compatibility.

Whilst this continue to function in 2.6, you should move to zones as soon as you can ideally as they will be taken out for good in future releases.

What about 3rd party shipping methods?

Like explained above, methods which do not define support for Shipping Zones will work as is – globally. Of course, moving to zones would be beneficial for their users, but this is not forced.

What about Table Rates?

The WooCommerce Table Rate Shipping extension had its own Shipping Zone system which this idea was based on. It was always the intention to some day roll this into core.

Table Rates are still mighty useful for defining rates based on weights, items counts, and customer spend so we’re going to continue to offer this extension, but it will be updated to use core zones instead.

When can I have it!

Zones will ship with WooCommerce 2.6 which is due for release Q2 2016. Please feel free to experiment and test with this functionality from Github master branch and provide feedback. It was merged today!

How can I support Shipping Zones?

Whilst not fully documented yet, you can refer to the Flat Rate Shipping class.

You define support for Instances and Zones and define settings per instance of your shipping method.

As long as you use the methods for retrieving options, you should be good to go as instances are handled in the abstract shipping class.

You can also still define global settings and support ‘settings’ to offer some options globally, which can be used in addition to instance settings. This will be useful for API based shipping methods who share settings between instances.


Keep yourself in the loop!

This field is hidden when viewing the form
This field is hidden when viewing the form
This field is hidden when viewing the form


41 responses to “Shipping Zones to ship with 2.6”

  1. That’s great news Mike, thank you!

  2. At last! Thanks!

  3. Will there be an easy migration from table rate to zones, if we’re only using the zone functionality of table rate?

    1. How can you use table rates with just zones and no rates?

      1. I haven’t looked at it in a while, but I think my client just has rates that are the equivalent of these new zones: some geographic areas with an associated shipping percentage. Or am I missing the difference between zones and rates? I know table rate seemed like overkill for what we did, but there wasn’t another option at the time.

        1. I think you’ll be using table rates within zones which is fine, they will port across.

  4. Glad to see this coming to core including continents 🙂

  5. Interesting feature. First tests revealed a dozen conflicts with a plugin I developed. It seems that the new WC_Settings_API introduced several methods that I had already added myself to a descendant of that class (they didn’t exist before). It’s a strange coincidence, I wonder if there was any sort of “inspiration” taken from the code I wrote.

    The issue is, the new methods all have different signatures, causing “signature mismatches”. I would really like not having to rewrite the entire class, as I must keep it 100% backward compatible with WC 2.5 and earlier (backward compatibility is vital), but I can’t find an alternative. Big issue, indeed.

    1. Are you serious 😀 I’ve never used one of your plugins or looked over your code. So no. No inspiration.

      Example error? Not much we can do if you’ve used the same name whilst extending.

      1. Some of the issues turned out to be related to scope (easy to fix). The main one is the method get_option_key(), which has a specific function in my plugins, and a different one in the base class (and also a different signature). Technically “I was there first”. 😀

        Now I’m looking for a way to change things without breaking anything, I will have to mark get_option_key as deprecated, not to be used.

      2. I also found a small bug, PR on the way.

    2. On the positive side, I like the idea that the shipping classes can now handle instance specific parameters. That’s exactly what I did when I implemented full multi-currency support for the shipping methods. Now the challenge will be supporting multiple instances of multiple instances. 😀

  6. This sounds really great Mike. But is there a way to add another layer of control and group these zones according to another condition like a vendor ID?

    I’m building a site where I have multiple vendors and I would like create vendor specific zones so that if a product is sold by Vendor A then the rate for shipping to “Local Zone = California ZIP 90210” could differ from what Vendor B is charging.

    1. Core doesn’t have a concept of vendors so I’ll say no. I imagine a vendor plugin could handle that within each rate or adapt zones however.

      1. Wouldn’t it be better though to be able to group zones? It doesn’t just apply to vendors, it could apply to members too.

        Then you could use the logic that if customer is in member group A use ‘shippingcost_group 1’. You could even make it that once a group of zones has been created you can just duplicate it and then modify just the changed values.

        There are lots of applications for this. Please re-consider. 🙂

        1. You’re asking us to introduce some form of customer role functionality. That’s a lot more in depth than it sounds 🙂

          1. No, I’m not asking for that at all. I’m only asking for a hierarchy where you can group zones, just like you can group products.

            The actual use and implementation of those grouped zones, ie how to assign them and when, would be left up to developers like us, or third party plugins. In fact that’s one more thing you can guys at Woo can sell. A plugin that then allows you to assign zone groups based on certain parameters.

  7. Just one question. Will we be able to match shipping classes with shipping zones? For example: I have some products in shipping class 1, someone in shipping zone A has to pay 5$ in shipping costs, and someone in shipping zone B has to pay 10$ in shipping costs for the same products. I hope I explained myself well enough.

    1. Classes are used within the shipping methods themselves. You’d configure this per method.

  8. If I’m already using the Table Rate Shipping Extension will I need to convert all those shipping zones/rates over to the core version? How will the Table Rates extension work with the core shipping zones?

    1. Did you read the post? Because that qu is answered..

  9. Will the zones from Woothemes Table Rate Shipping extension migrate to the core zones and its db table be cleaned up ?

    1. Yeah, we’ll handle this.

  10. Nice

  11. This sounds fantastic. Many thanks for including this in core. I can’t wait to try it out… 🙂

  12. Installed ‘2.6.0-beta-1’ (thought I was installing 2.5.5 but used svn). We have the table rates shipping plugin (2.9.2). The site crashed with a Cannot redeclare class WC_Shipping_Zones error. The only way to get things back up was to deactivate the table rates shipping plugin. Should I install 2.5.5 instead?

    1. We’ve not released the compatibility update for TRS yet.

      1. That makes sense. I rolled back to 2.5.5 and things are working much better.

  13. […] some major changes in it, for compatibility with the forthcoming WooCommerce 2.6, and particularly the new “Shipping Zones” feature. This will allow you to set different times for each shipping zone instance. So, flat-rate local […]

  14. […] We made a more detailed post about Shipping Zones which you can read here. […]

  15. Is it save to update Woocommerce to 2.6 whenmy shop uses Woothemes Table Rate Shipping extension? Or will there be conflict?

    1. It will conflict unless you update to table rate shipping v3 first.

      1. Thanks for your quick reply!! Where do I do this? I have the latest version of the plugin: Woothemes Table Rate Shipping extension

        1. It needs to be v3.0 – download from your woothemes account if its not what you’re running.

          1. I understand, thanks for the help. I’m getting ready to update. Is their a process i need to follow like deactivate plugin update plugin and then update woocommerce? I don’t see anything in the documantation?

          2. No, but you should definitely check your plugins + theme are also compatible first, and preferably test on a staging environment.

            https://www.woothemes.com/2016/05/prepare-woocommerce-testing-backups/

          3. Works perfectly on my stage enviorment! Thanks for the quick help. I have only one problem that when you delete item from shoppingcart it says “undo” where in the previous version it would say it in correct language but I think this is Woocommerce/Storefront. Thanks again!

  16. FYI – The PRODUCT PRICE BASED ON COUNTRY plugin affects shipping zones in a weird way – Doesn’t let WC find Shipping zones.

  17. […] states, and zip codes into a ‘zone’ and then add shipping methods to each. Here’s a more detailed post about shipping […]

  18. God. I’v e spent half a day trying to get shipping options to work properly.. I’ve got zones and shipping medthod for each zone. Will they appear as options at the Cart stage! NOPE.

    1. There is a debug mode in system status tools you can use to see if they are matching. Check that and use the forums if you need help.

Leave a Reply

Your email address will not be published. Required fields are marked *