fix: accept Latvian postcodes without the LV prefix hyphen - #67684

Submission Review Guidelines:

• I have followed the WooCommerce Contributing Guidelines and the WordPress Coding Standards.
• I have checked to ensure there aren't other open Pull Requests for the same update/change.
• I have reviewed my code for security best practices.

Changes proposed in this Pull Request:

Fixes a regression from #67460. WC_Validation::is_postcode() does not normalise its input, so a Latvian postcode can reach it carrying the LV prefix with a hyphen, with a space, or with no separator at all. The rule added in #67460 required the literal hyphen, so it rejected the other two forms. Before that PR, Latvia had no rule and all three fell through to the fail-open default, so all three were accepted.

-case 'LV': preg_match( '/^(?:LV-)?[1-9][0-9]{3}\z/i', $postcode );
+case 'LV': preg_match( '/^(?:LV[- ]?)?[1-9][0-9]{3}\z/i', $postcode );

A literal space rather than \s, so a newline or tab between the prefix and the digits is still rejected and the \z anchor keeps doing its job (see #67667).

How a normal request reaches that state

AbstractAddressSchema::sanitize_callback() formats the postcode using the raw country value, while the country itself is uppercased. The array_reduce closure captures $address by value, so it never sees the uppercased $carry:

case 'country':  $carry[ $key ] = wc_strtoupper( sanitize_text_field( $address[ $key ] ) );
case 'postcode': $carry[ $key ] = wc_format_postcode( sanitize_text_field( $address['postcode'] ), $address['country'] );

For a client sending {"country":"lv","postcode":"LV-1050"}:

1. wc_normalize_postcode() strips the hyphen, giving LV1050.
2. wc_format_postcode()'s case 'LV', which would reinsert the hyphen, is skipped because $country is lv.
3. The postcode is then validated against the uppercased country, so the LV case in is_postcode() does fire, against LV1050, and rejects a valid postcode.

This is reachable through POST /wc/store/v1/checkout, and I reproduced it end to end. On trunk that request is rejected with rest_invalid_param, "The provided postcode / ZIP is not valid". On this branch it creates the order.

POST /wc/store/v1/cart/update-customer is not affected, which is worth knowing since it is the obvious route to reach for. It sanitises before validating, and validate_callback() then re-runs sanitize_callback() on the already-sanitised array. That second pass sees the uppercased LV, so wc_format_postcode() restores the hyphen and is_postcode() receives LV-1050. The double sanitise is accidentally self-healing there.

Direct callers are not self-healing either, for example WC_Validation::is_postcode( 'LV 1050', 'LV' ).

Classic checkout and the blocks checkout UI are unaffected, because they send uppercase country codes and so reformat correctly.

Backward compatibility

No signature, return type or hook change. WC_Validation::is_postcode() keeps its ( string $postcode, string $country ): bool shape, and woocommerce_validate_postcode fires with the same three arguments.

The behaviour change is strictly more permissive: the pattern now accepts a superset of what it accepts on trunk, so nothing that validates today starts failing. Extensions that call is_postcode() directly (WooCommerce Subscriptions, WooPayments, Stripe, PayPal Payments) only see previously-rejected values start passing. Every value this newly accepts was accepted before #67460.

Scope

Deliberately limited to restoring what #67460 took away.

DK has the identical bug from the same cause, and is_postcode( 'DK1050', 'DK' ) returns false on trunk today. It is not a regression, it has been that way for years, and folding it in here would mean this fix could not be reverted or cherry-picked without dragging Danish postcode rules along. It is handled separately in #67685.

The underlying raw-vs-uppercased country asymmetry in sanitize_callback() is the real root cause, and the state branch above it has the same problem. Fixing that changes behaviour for every country in the wc_format_postcode() switch, so it needs its own PR and its own testing. It fits naturally with the validation unification work in #66953.

(For Bug Fixes) Bug introduced in PR #67460.

How to test the changes in this Pull Request:

Unit tests

1. Run pnpm --filter=@woocommerce/plugin-woocommerce test:php:env -- --filter WC_Validation_Test.
2. Confirm all tests pass. Check out trunk and rerun to see the new LV1050 and LV 1050 rows fail.

Store API, the reported path

1. Add an item to the cart so /checkout is reachable, keeping the Cart-Token and Nonce headers from the response.
2. On trunk, place an order with a lowercase country code and a prefixed Latvian postcode:

   POST /wp-json/wc/store/v1/checkout
   {"billing_address":{...,"postcode":"LV-1050","country":"lv"},
    "shipping_address":{...,"postcode":"LV-1050","country":"lv"},
    "payment_method":"cod"}
   

3. Confirm you get a 400 rest_invalid_param, "The provided postcode / ZIP is not valid".
4. Check out this branch and repeat. Confirm the order is created.
5. Confirm {"country":"lv","postcode":"LV-0123"} is still rejected on both.

Note that POST /cart/update-customer accepts all of these on trunk too, for the reason described above. Use /checkout to see the difference.

No regression on the normal path

1. Enable Latvia as a selling country.
2. Add a product, then go to both classic and blocks checkout.
3. Enter Latvia with LV-1050, then 1050. Confirm both are accepted.
4. Enter LV-0123 and LV-105. Confirm both are still rejected.

An earlier version of step 3 said each value "normalises to LV-1050" and included LV 1050. Thanks to @jorgeatorres for catching that. Neither part is right for the blocks checkout, and neither is affected by this PR:

• The blocks checkout never writes the server formatted postcode back into the field. POST /cart/update-customer does return LV-1050 for an entered 1050, but the input keeps showing what you typed. wc_format_postcode() still runs before the value is stored, so the order gets LV-1050.
• LV 1050 is rejected client side with "Please enter a valid postcode", before any request is made. The blocks checkout has no LV entry in its own CUSTOM_REGEXES, so it falls through to the postcode-validator package, which uses /^(LV-)?\d{4}$/.

That client rule disagrees with the server one in both directions. It is stricter about the prefix (lv-1050, LV 1050 and LV1050 are all rejected) and looser about the value (0123 and LV-0123 pass client side and are then rejected by the server). Worth fixing separately, by adding LV to CUSTOM_REGEXES in is-postcode.ts. Out of scope here, since this PR is a server side regression fix and touching the client rule would change which values the form accepts.

Testing that has already taken place:

• WC_Validation_Test run in wp-env (PHP 8.1.34, PHPUnit 9.6.35): 34 tests, 36 assertions, all passing.
• 10 new data-provider rows covering the un-hyphenated and space-separated prefix forms, case insensitivity, newline and tab rejection, and the existing rejections.
• Reproduced and verified over real HTTP against a local store, on trunk and on this branch, swapping only class-wc-validation.php between the two so nothing else differed. POST /wc/store/v1/checkout with country: "lv" and postcode: "LV-1050" is rejected on trunk and creates an order on this branch. country: "LV" succeeds on both. LV-0123 is rejected on both.
• Instrumented the woocommerce_format_postcode and woocommerce_validate_postcode filters with backtraces to confirm exactly which country and postcode values reach is_postcode() on each route, rather than inferring it from reading the code. That is how the update-customer self-healing was found.
• Followed up on @jorgeatorres's review in the blocks checkout: entered LV 1050 and 1050 for Latvia and read the resulting field state, the client validation errors and the update-customer response. Confirmed the client rule rejects LV 1050, the field is never rewritten with the server formatted value, and the shipped isPostcode() disagrees with the server for lv-1050, LV1050, 0123 and LV-0123. All of that is the same before and after this PR.
• phpcs-changed clean on the changed files and on the full branch diff. PHPStan clean on includes/class-wc-validation.php.
• Not tested on multisite. The change is a pure regex and reads no site state, so multisite behaviour is unchanged.

Milestone

• Automatically assign milestone for the next WooCommerce version

Changelog entry

Changelog entry added manually in plugins/woocommerce/changelog/fix-lv-postcode-separator.

Use of AI Tools

Found by the AI regression review bot (WOOAIRR-53) against #67460. Its report named /cart/update-customer as the reproduction, which turned out not to reproduce; I traced the real path to /checkout and confirmed it against a running store before writing the fix. Claude Code assisted with the patch, the test rows and this description. I have reviewed all of it and take responsibility for it.

🤖 Generated with Claude Code