Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.Currently zones are config entities with their own UI, they can embed any number of ZoneMember plugins, with three types existing currently:
1) Country (match by country, subdivision, postal code(s))
2) EU (match whether the address belongs to the EU)
3) Zone (match by another zone)
The idea was that conditions (on shipping methods, etc) would reference the zone entity.
Therefore, the zones are not really standalone, they are primarily important for conditions on another entity or somewhere in code.
However, this approach proved to be not very practical:
1) Performance reasons: why load another entity per condition, when the condition can have any serialized data, including the zone
If we have 20 tax types (or shipping methods), that's 20 additional entities to load for no reason.
2) UI reasons: There's a need to jump to another UI, then come back, instead of just performing the task inline.
Therefore, my proposal is to remove the Zone config entity and ZoneMember plugin type completely.
Instead, have an "Address belongs to zone" condition that can have any number of country conditions (country/subdivision/postalcode) that are OR-ed together.
The "Zone" zone member disappears cause there's no entity to reference anymore.
The "EU" zone member becomes a separate condition "Address belongs to the European Union".
This solves both of our problems. There is a small cost to pay, a zone can no longer have multiple zone member types (EU + a country one). This simplifies the UI further, but it means that more advanced use cases like those will need custom conditions written.
This is also a fairly big BC break, any existing zone data will be completely lost, we have no way to migrate it.
On the other hand, I'm unsure anyone actually used the Zone functionality?
Comments
Comment #2
bojanz CreditAttribution: bojanz at Centarro commentedComment #3
mglamanI don't think any modules implemented this, and the UI was pretty buried in Config -> Region -> Zones.
So instead of a config entity representing the zone, it's just a highly customizable condition plugin. Which means it is not reusable across different requirements, but easily implemented nonetheless.
I think this could be fine because as you said, it just serializes that config in the entity it's embedded in and not its own storage. The use cases I can think of were promotions only within the continental US for free shipping and also within a shipping method. Reproducing that twice couldn't be hard. Especially if it could just as easily be provided in code.
Comment #4
pcambraJust pointing to this D7 implementation of the Zones library: https://www.drupal.org/project/address_zone it implements a json file for each zone and exposing that to rules and inline conditions.
Comment #5
lisastreeter CreditAttribution: lisastreeter as a volunteer commentedI agree that a simplification of zones with an resulting performance improvement would offset the downside of breaking BC. I can think of two non-shipping use cases:
1. Stores could have exclusive distributors for particular zones. (Small companies, in particular, often use international distributors, since they are not equipped to handle currency/language issues internally.) A customer wanting to place an order from an exclusive zone/country might need to be blocked/redirected to the distributor. If the distributors are country-based, this can be handled easily using the "Supported billing/shipping countries" options for stores, but zones make more complex restrictions possible.
2. Stores that have territorial sales reps could create a zone condition for each rep and then assign orders/customers to a specific rep based on the condition. These assignments can be used for commission calculations. Here, country/subdivision/postalcode conditions would likely be necessary.
Comment #6
bojanz CreditAttribution: bojanz at Centarro commentedIt has been decided.
The addressing library now contains the new simplified zone functionality: https://github.com/commerceguys/addressing#zones
In this module we remove the zone config entity & plugins. We provide a zone_territory form element (and latter maybe a zone one as well).
Then in a followup we implement a condition that uses it. Can't do it right now cause I need to figure out how to make it useful, core conditions don't use context, and Commerce has its own condition plugins. Perhaps the solution is to provide a Rules condition instead.
Still nervous about doing this in a release candidate, my apologies to anyone silently affected.
Comment #8
bojanz CreditAttribution: bojanz at Centarro commentedHere we go.
Comment #9
bojanz CreditAttribution: bojanz at Centarro commented