lsinger
commented
3 years ago Hi @PatrickCaneloDigital,
Thank you for taking the time to share this idea, we really appreciate your help.
Have you tried using an extension to achieve your goal? A quick search found this plugin, for example. Note that I haven't tried it myself.
woocommercebot
Prerequisites (mark completed items with an [x]):
Describe the bug Woocommerce shipping zones support is built on a logic which is not worldwide appliable: Country > States > Postcode What can work in some countries, does not work in lots of other countries, where Postcodes are simply not used because there are more private companies covering traditional postal shippings, or because postal codes have become obsolete in their usage. In these countries (e.g. Chile) the geografical brakdown is structured as country > region/state > county/comune/city
So when we look at the Shipping zone support, Chile does not offer any regions. but off course there's the filter to include them. so far so good... Until a while ago, when stores had to implement free or flat rate shipping based on counties/comune, one simply redefined Chiles regions using the counties, because the flat rates are most times not on regional level but on county/comune level.
a few versions of woocommerce ago these stores began to have problem: During checkout process the state/regions field is checked against that injected state list, so all the stores who had configured comunes instead of regions (to be able to offer flat rate per commune), get now errormessages when users try to go to payment with errormessage: region/state must be one of the following.
And yes, I get it: comunes is a input field, so city and region names can be written differently which makes it harder to use for an equal matching... but in some cases, as in chile, most webstores use dropdowns provided by an API of a shipping-service or any other national DB...
But resuming the bug is: In contries where no postcodes are used, the new checkout check (is region in array defined regions) is logically sound, but together with the fact that there are many countries where no postcodes are used, produces problems when defining shipping zones.
Expected behavior Shipping zone support should follow the usual mandatory field structure during checkout: Country > Region/state > City/Comune > Postcode To avoid spelling problems, instead of choosing cities/comunes by multi-select it could be an option to have a text list to define a shipping zone...
I know there are some technical issues with this expected behaviour, but at the other hand we're out of solutions with filters, etc. In countries where no postcodes are used, there is no simple way to define shipping zones on commune/county/city level.
Actual behavior Shipping zones cannot be defined on City or Comune level by their name, only by region & postcode, which for lots of southern hemisphere countries is not practically appliable.
So the bug is: Either conceptual: I cannot define a shipping zone by city/comune or technical: the newly introduced checking of billing_state against defined regions in add_filter('woocommerce_states',...) during the checkout, is logically sound, but blocks all sites which had to define flat rates or free shipping on comune/city level without postcode and used a workaround...
Steps to reproduce the bug (We need to be able to reproduce the bug in order to fix it.) Steps to reproduce the bug:
Screenshots During checkout, since a few weeks, stores get this error if they were overwriting the countries regions with their counties... Billing region/province not valid... must be one of .......
Isolating the problem (mark completed items with an [x]):
WordPress Environment We use the WooCommerce System Status Report to help us evaluate the issue. Without this report we won't be able to fully evaluate this issue.