Phone number validation - problem for some customers



  • A customer wrote today saying they couldn’t order because their phone number was being rejected as invalid.

    I followed the instruction here https://www.prestashop.com/forums/topic/393876-how-disable-phone-number-format-check/

    and did this:

    Find in classes/Validate.php

    public static function isPhoneNumber($number)
    	{
    		return preg_match('/^[+0-9. ()-]*$/', $number);
    	}
    

    and change to:

    public static function isPhoneNumber($number)
    	{
    		return true;
    	}
    

    I’m wondering what the customer might have entered that gave the error. Do I read the original code properly that it demands a plus? If so, it might be a good idea to change that. I’m sure this affects lots of customers.



  • Waiting for the reply. 🙂 If it’s not the plus, I’m wondering whether she used the letter oh instead of a zero.

    Thanks for the explanation of the *!



  • For debugging you can change this validation method to this:

    public static function isPhoneNumber($number)
    {
        if (!preg_match('/^[+0-9. ()-]*$/', $number)) {
            file_put_contents(_PS_ROOT_DIR_.'/config/phonenumbers-failed', var_export($number, true)."\n", FILE_APPEND);
        }
    
        return true;
    }
    

    This will create a file config/phonenumbers-failed and list all the failed phone numbers inside there. Still report success in any case.



  • @traumflug Thank you! I’ll add the code right away. The customer still hasn’t replied.



  • My guess would be that for some reason she cut & paste her phone number into the field and inadvertently included a trailing CR, LF, tab, etc. Alternatively if she c&p from Word it could have had the dashes replaced with special characters.

    Another problem that happens with customers from some countries is they end up using double width numbers instead of half width (aka normal) numbers.



  • inadvertently included a trailing CR, LF, tab,

    tripping over such a situation would be a bug.



  • @traumflug said in Phone number validation - problem for some customers:

    inadvertently included a trailing CR, LF, tab,

    tripping over such a situation would be a bug.

    After a little testing it will fail if a tab is included but CR LF seem to be replaced with a space. Using an em dash will also cause validation to fail.

    My expectation would be that any special character, visible or not (besides CR LF), will cause phone number validation to fail.





  • Unless the phone number field is to be used for auto-sending SMS or something like that then is validation really needed at all?

    Removing validation would allow customers to include extension numbers (common for offices) or other bits of info that might occur in some phone numbers.



  • As @mdekker mentioned in the Github issue, such phone numbers potentially get sent to many places, like carriers, payment processors or similar. Shaping the number would avoid it becoming stuck later.

    With ‘shaping’ I mean things like replacing all the various whitespace types with an ordinary space character, replacing various dash types with the ordinary minus sign and such stuff.



  • Such shaping is going to be difficult with the nearly endless number of unicode characters. Japanese alone has 7 or 8 different dash type characters, and that’s not including the funky ones that are dash-like but not actually dashes. I expect other complex languages will have similar numbers to deal with. There are also 9 or 10 different possible bracket styles in Japanese. Crazy, yes.

    It’s probably best to give people a list of valid characters they can use and then either refuse to accept input with invalid characters (like now) or brute-force strip invalid characters with Regex.


 

Looks like your connection to thirty bees forum was lost, please wait while we try to reconnect.