US Zip Code - Validate 2 formats

[Rhapsody]

The zip/postal code in the US has the basic 5 digit code ( e.g. 12345) and an optional suffix with a hyphen followed by 4 digits (e.g. 12345-1234).  Is there a method to validate both formats when an address is entered?  Setting either format in the Country works, but only a single format is validated.  

[DRMasterChief]

Hi,  can someone please tell me if the 'optional suffix'  (-1234)  is common for US citizens?  We have some orders from USA and no one give this at the order.   We have to search this manually each time,  as it is very important for the shipment abroad.... 

I think the validation of both formats is useful,  maybe the customers can/should be forced in any way to give the suffix voluntarily  🙂

thank you

[colorful-ant]

optionally leave the zip code field empty and save it

 

[Rhapsody]

On 4/9/2020 at 4:31 PM, colorful-ant said:

optionally leave the zip code field empty and save it

I am aware of this option but would rather have the input validated.

[the.rampage.rado]

In the current situation - it cant' be done.

If you like you can make a PR @github with the preffered version but consider not only your case but any other use scenario that may arrise. If NNNNN is the US standard I would like to leave it as is. I have shipped to USA and Costa Rica with no problem with only NNNNN.

[Rhapsody]

Which file is used to validate the postal codes?  I'll take a look at that.

never mind - I found it in classes/validate.php 

This is the current code used to validate 

/**
     * Check for zip code format validity
     *
     * @param string $zipCode zip code format to validate
     *
     * @return bool Validity is ok or not
     *
     * @since   1.0.0
     * @version 1.0.0 Initial version
     */
    public static function isZipCodeFormat($zipCode)
    {
        if (!empty($zipCode)) {
            return (bool) preg_match('/^[NLCnlc 0-9-]+$/', $zipCode);
        }

        return true;
    }

20 hours ago, the.rampage.rado said:

In the current situation - it cant' be done.

If you like you can make a PR @github with the preffered version but consider not only your case but any other use scenario that may arrise. If NNNNN is the US standard I would like to leave it as is. I have shipped to USA and Costa Rica with no problem with only NNNNN.

 

Edited April 17, 2020 by Rhapsody

[Traumflug]

3 hours ago, Rhapsody said:

return true;

This means an empty ZIP code is recognized as valid code, which is probably not what you want.

[lesley]

In the US people do not normally use the dash 4 digits. Some do, just because it is store from some other transaction. Since the US is one of the only countries with this zip code issue, if it bothers you I would handle it at the template level. Just split the string at the - and drop the extra 4 digits and the dash. They add no value in either delivery or tax collection. 

[Rhapsody]

lesley,

Thanks for the comment.  The +4 is used for the automated mail sorting at the postal centers so it does help.  This from the USPS website:

Quote

The ZIP+4® Code assigned by the Postal Service™ is unique for the category of Reply Mail you use.  This unique ZIP+4 code enables Reply Mail to be sorted on postal automated equipment by specific size and weight (i.e., cards, 1oz. letters, 2 oz. letters, etc.).

 

The problem with not having both formats available is when a user saves a format that is not validated, it gives an error.  Currently only a single format is validated.  I am going to play with some ideas on how two formats may be saved and validated. Possible save two formats in the definition field using a comma seperator.  During the check, if a comma is detected in the definition field split into two instances and check if either validates properly.  

Once I have a working concept, I'll post here for comments.

8 hours ago, lesley said:

In the US people do not normally use the dash 4 digits. Some do, just because it is store from some other transaction. Since the US is one of the only countries with this zip code issue, if it bothers you I would handle it at the template level. Just split the string at the - and drop the extra 4 digits and the dash. They add no value in either delivery or tax collection.