WooCommerce Core

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 Woothemes 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.

By Mike Jolley

Mike Jolley is a tech hobbyist, astrophotographer, retro gamer, and software engineer who works at Automattic and contributes to open-source projects such as WordPress and WooCommerce.

41 replies on “Shipping Zones to ship with 2.6”

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.


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.


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.


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. 😀


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.


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. 🙂


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.


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.


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?


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


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?


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


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


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?


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!


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.


Comments are closed.