Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[3.x]: Shipping method zipCode check is cached with wrong value #2842

Open
WHITE-developer opened this issue Jun 9, 2022 · 5 comments
Open
Assignees
Labels
bug commerce3 Issues related to Commerce v3

Comments

@WHITE-developer
Copy link

What happened?

Description

We have a handfull of orders/carts where the zipCode check for the shipping zone is returning false (value of the check is already cached with a false value), while if I debug in the method https://github.com/craftcms/commerce/blob/v3/src/services/Addresses.php#L419 the evaluateCondition would return true
https://i.imgur.com/nSneGMx.png

Because of this a lot of our shipping methods are not shown in the checkout process.

But also some orders still where completed where they have selected a shipping method linked to the same zipCode check, and the cp panel is also showing it is linked to this shipping method, but in a later stage for example downloading an order pdf where we query for order.shippingMethod is return null

Craft CMS version

3.7.38

Craft Commerce version

3.4.14

PHP version

8.0.19

Operating system and version

No response

Database type and version

No response

Image driver and version

No response

Installed plugins and versions

No response

@WHITE-developer WHITE-developer added commerce3 Issues related to Commerce v3 bug labels Jun 9, 2022
@nfourtythree
Copy link
Contributor

Hi @WHITE-developer

I can't seem to replicate this issue, everything appears to be working as expected. I tried using the regular expression from your example and things worked smoothly.

What caching method are you using?

The only thing I could think of is that maybe the cache key is messing up due to it having a regular expression in it. But this seems unlikely due to the fact it is simply a string.

You could try updating this line: https://github.com/craftcms/commerce/blob/v3/src/services/Addresses.php#L417 with:

$cacheKey = get_class($zone) . ':' . md5($conditionFormula) . ':' . $zipCode;

And see if that solves the issue, but unfortunately at the moment, I can't see what would be causing the behaviour you are seeing.

Thanks.

@nfourtythree nfourtythree added ℹ️ status: need more info When waiting for user to supply database or more information. and removed bug labels Jul 11, 2022
@gazlawn22
Copy link

We also recently hit this issue, a client was testing and was hitting no available shipping methods, adding in @nfourtythree change made it work.

One thing that could of happened, is that our client uses a lot of shipping formulas, and while I don't have this confirmed, I would imagine that they had used their postcode to test certain rules, and then removed and maybe it was getting left in the cache there (but I am way out of my own depths here).

@nfourtythree nfourtythree added bug and removed ℹ️ status: need more info When waiting for user to supply database or more information. labels Aug 5, 2022
@nfourtythree
Copy link
Contributor

3.4.16 is now out with this fix.

@matt-adigital
Copy link

Hi, we are running Commerce 3.4.16 and are still seeing this issue.

Our client is reporting this daily to us that customers are complaining the site doesn't ship to them, but it is configured so that it should. This is specifically a postcode based shipping zone and postcode tests succeed against the zone within the cms when we check them after being reported. They have provided screenshots of the message on the checkout process and also of the cms pages where the shipping method dropdown has only one option named "None". However when we go into the cms and check it later the options have suddenly appeared again, clearing the cms caches through the utility seems to fix this but it is causing a lot of frustration for this client and their customers.

Can we please reopen and take another look please? If you need any additional details then please let me know. Thanks.

@sunnylawn
Copy link

We're still having an issue with this, to the point where we have 5 shipping zones, UK Mainland, Isle of Man, Scottish Highlands, and Jersey and Guernsey and Northern Ireland, all of which have rules set up to specify that the postcode must match a formula:

zipCode[0:2] == 'IM' or zipCode[0:2] == 'im'

If I'm understanding this right, the above (Isle of Man) should only display if a users Postal Code begins with IM/im?

e.g. Northern Ireland is set up to only appear for Postcodes beginning with BT/bt.

We also have a UK Mainland Delivery which then excludes a lot of the postcodes that have been added in via the following format...

not(zipCode[0:2] starts with 'BT') or not(zipCode[0:2] starts with 'bt') or not(zipCode[0:4] starts with 'AB36') or not(zipCode[0:4] starts with 'AB37') or not(zipCode[0:4] starts with 'AB38')

This list has about 600 postcodes in it, though half have been added in uppercase the other half in lowercase (not sure if this is case sensitive).

What is happening though is all 5 of those shipping rules are appearing as options, resulting in pretty much a 100% wrong shipping method being selected for users outside of UK Mainland, e.g. Highlands/Northern Ireland etc are selecting Mainland which is significantly cheaper.

From what we can see our formula is right (though would be happy if it is just incorrect format), but does seem to be more about internal caching?

Any help would be appreciated...

Running Craft 3.8.5 and Commerce 3.4.20.1

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug commerce3 Issues related to Commerce v3
Projects
None yet
Development

No branches or pull requests

6 participants