Jump to content
  • Checkout
  • Login
  • Get in touch

osCommerce

The e-commerce.

Conditional formatting an input field


ArtcoInc

Recommended Posts

Here in the Unites States, our telephone numbers are formatted as:

123 456 7890 (spaces added for clarification)

The country is broken up into various (and sometimes overlapping) Area Codes. The first three digits of our phone numbers are the Area Code, and the last 7 digits are the actual phone number.

In osC, the telephone number field is an unformatted text field. This allows users to enter letters, numbers, and characters. This is important if the customer needs to add, say, a business extension (ex: 123 456 7890 x123).

Sometimes, our customers format their phone number, and sometimes not. Without formatting, it can become difficult to read the phone number.

For example: 1234567890 can be difficult to read.

Where as,

123.456.7890
123-456-7890
123 456 7890
(123)456-7890
etc

are all much easier to read.

It would be simple enough to simply apply a mask to the input field, but we do have international customers, where the phone number format can be different.

So, my though is: Can one apply conditional formatting on an input field, based on a condition (for this example, the customer's country)? And, could the resulting formatting then be applied when saving the data (in this example, a phone number) in the database?

I realize that there would be exceptions ...

1) Other countries, such as Canada, also have the same telephone number formatting as the United States. A field could be added to the Countries table to account for the different formatting in each country.

2) A Customer may have a different country (and thus telephone number format) for their billing and shipping addresses.

3) etc.

 

Yes, I realize that adapting something like this would require core changes.

Thoughts?

Malcolm

Link to comment
Share on other sites

If you want, you can be a guinea pig for this HT module.

tel_format.jpg.41c1fc3093ffa8ea5b953df43a5f01ea.jpg

This script [with no core code changes ;)] adds in flags and adds in a different placeholder per country.  This does not do any formatting but gives a kind of prompt to help users to set out their number as per the placeholder.

Downside is that there isn't a way (without core code changes) to automatically set the telephone->country when the main country field is filled out.  However, it is possible to geolocate when the create_account page is loaded.  As 99% of shoppers doing their shopping are in their country of residence, it shouldn't be a problem.  

 

Link to comment
Share on other sites

Burt's way does seem better, but I did this a long time ago by creating this function

// format phone numbers for US
  function tep_format_phone($subject) {
    $result = preg_replace('/\(?\b([0-9]{3})\)?[-. ]?([0-9]{3})[-. ]?([0-9]{4})\b/m', '$1-$2-$3', $subject);
    return $result;
  }

then in create account I did this

   $telephone = tep_db_prepare_input(tep_format_phone($_POST['telephone']));

 

I'm not really a dog.

Link to comment
Share on other sites

Thank you @burt. Your HT module is another example of your great coding skills! While it does offer a placeholder that shows the 'preferred' format (based on the selected country), the customer is still free to enter whatever they want.

So, I started to think about my options. I *could* ...

1) Let the customer enter whatever they wanted, then 'sanitize' the data (the sanitization may, or may not, be country specific) before storing it in the database, or

2) Let the customer enter whatever they wanted, save the data as entered, and then 'sanitize' it when displaying it (for example, in Admin, where I need to be able to read it easily), or

3) Provide a mask, forcing the customer to enter the data in the format of my choice (which, again, may or may not be country specific).

Thoughts? TIA!

Malcolm

Link to comment
Share on other sites

How many countries do you sell to?  I only sell in the US, so I made mine format to the way I wanted it, but you could do more formats based on countries.  Obviously, I made core changes, but I did this years ago.

The function I posted could easily be modified to only format when the country is the United States if that is the one you want to format.

I'm not really a dog.

Link to comment
Share on other sites

@John W

The majority of my business is in the US, but I have shipped to every continent short of Antarctica.

It shouldn't be too difficult to add a check for the country, and add the masking only if the country is the US.

Yes, this would be a core change. But, it's not like I haven't made any other core changes. In for a penny, in for a pound :cool:

Malcolm

Link to comment
Share on other sites

Even if you only format it for the US, it makes it better.  I'm glad I did it way back, becuase it was driving me nuts and that's a short trip for me.  You could just put the conditon if the function I showed to only format US.  You can see I format it to $1-$2-$3, but you could change to whatever you want.  You can probably find regex already done for different countries online.

I'm not really a dog.

Link to comment
Share on other sites

Yeah, it's just a helper.

I've always been of the opinion that any data inputted by the customer should remain exactly as input.  I can however see that this sometimes is not preferable for the shopowner.

Another idea;

new admin page which lists all the countries, each country has three new input boxes.
1 input box for a placeholder 
1 input box for a pattern
1 input box for an explanation (of the pattern)

a HT module which loads the correct placeholder AND the correct pattern for the selected country.

No core code changes... and does everything you want...
However, that is a project that would need time and attention to detail.

Link to comment
Share on other sites

@burt

Different countries have all sorts of rules defining how an address (and phone number) are entered. If we carried this to the 'logical' (extreme?) conclusion, we could have ALL sorts of country specific formatting when a customer enters their information.

Then again, have you read about the complicator's gloves? :rolleyes:

@John W

In your early code example, it appears that you are altering the phone number before it is saved to the database. As @burt said:

On 10/28/2017 at 4:49 AM, burt said:

I've always been of the opinion that any data inputted by the customer should remain exactly as input.  I can however see that this sometimes is not preferable for the shopowner.

So, I'm now trying something else ...

I'll let the customer enter their number however they wish. Then, where that number is displayed (say, in /admin/orders.php), I'll format how the number is displayed. Here's my first draft at that ...

<?php
              // Format the phone number if the customer is from the United States
              if ($order->customer[country] == "United States") {

                $raw_telephone = $order->customer['telephone'];

                // Strip away all the non-numberic characters
                $formattedPhoneNumber = preg_replace('/[^0-9]/','', $raw_telephone);

                // Strip leading 0's or 1's
                $continue = 'false';
                while ($continue == 'false') {

                  // If the first number is a 0 (denoting international), delete it
                  if (substr($formattedPhoneNumber, 0, 1) === '0') {
                    $formattedPhoneNumber = substr($formattedPhoneNumber, 1);

                  // If the first number is a 1 (denoting the US country code), delete it
                  } else if (substr($formattedPhoneNumber, 0, 1) === '1') {
                    $formattedPhoneNumber = substr($formattedPhoneNumber, 1);

                  } else {
                    $continue = 'true';
                  }
                }

                // If more than 10 numbers, assume that any 'extra' numbers are a telephone extension
                if(strlen($formattedPhoneNumber) > 10) {
                  $areaCode  = substr($formattedPhoneNumber, 0, 3);
                  $nextThree = substr($formattedPhoneNumber, 3, 3);
                  $lastFour  = substr($formattedPhoneNumber, 6, 4);
                  $extension = substr($formattedPhoneNumber, 10, strlen($formattedPhoneNumber)-10);
                  $formattedPhoneNumber = '('.$areaCode.') '.$nextThree.'-'.$lastFour.' x'.$extension;

                // If only 10 numbers, format with the area code
                } else if(strlen($formattedPhoneNumber) == 10) {
                  $areaCode  = substr($formattedPhoneNumber, 0, 3);
                  $nextThree = substr($formattedPhoneNumber, 3, 3);
                  $lastFour  = substr($formattedPhoneNumber, 6, 4);
                  $formattedPhoneNumber = '('.$areaCode.') '.$nextThree.'-'.$lastFour;

                // If only 7 numbers, format without the area code
                } else if(strlen($formattedPhoneNumber) == 7) {
                  $nextThree = substr($formattedPhoneNumber, 0, 3);
                  $lastFour  = substr($formattedPhoneNumber, 3, 4);
                  $formattedPhoneNumber = $nextThree.'-'.$lastFour;

                // Otherwise, the customer didn't enter a complete phone number
                // Display the raw number unformated (and indicate that it is unformated)
                } else {
                  $formattedPhoneNumber = '<i> (unformated): </i> ' .  $raw_telephone;
                }

                echo $formattedPhoneNumber;

              // If the customer is NOT from the United States, display what the customer entered, with no formatting
              } else {
                echo "Some other country " . $order->customer['telephone'];
              }
?>

(I'm sure it could be cleaned up further, and/or turned into a function)

Malcolm

Link to comment
Share on other sites

Yes, I'm formatting it as it's inserted into the database and have done that for years with no problems. Like you, I hate it when they put it in as 1234567890, but I'm a little anal about some things.  I also have been using the function ucwords to capitalize names and addresses for a very long time.

I have to say also that the Google autocomplete for addresses works really well for me with only a few issues that I was able to solve.  Far less zip code missmatches compared to before.

I'm not really a dog.

Link to comment
Share on other sites

Archived

This topic is now archived and is closed to further replies.

×
×
  • Create New...