BE input field "phone" space character

[Teisi]

Space character at the input field "phone" does not work. It deletes the space every time.

[BastianBalthasarBux]

That's so true! :-) Look: https://github.com/BastianBalthasarBux/tt_address/blob/master/Classes/Evaluation/TelephoneEvaluation.php

But i see, there could be some reason for formatting the output for readability. While in DB we only want valid Phonenumbers, for good reason, which could e.g. be linked with a href="tel:+431231232123" ... (therefore you could just tap the number to dial on your mobile devices, but also if you have e.g. a software sip-phone on your desktop, or the like).

Your further suggestions on how to proceed on that "problem" are welcome ...

[Teisi]

Oh like a viewhelper... it is not nessasary to write +49 or 0049 or something in the BE - this adds my viewhelper if you haven't set it in the backend input field. To make a number clickable - if you like it, your welcome to add it.

Forgotten to say: white spaces are also no problem.

<?php
namespace name\ext\ViewHelpers;

use TYPO3\CMS\Fluid\Core\ViewHelper\AbstractViewHelper;

/**
 * ViewHelper to render a phone link
 *
 * # Example: Basic example
 *
 * <code>
 * <hh:phonetolink number="5684325" title="my title" class="phone" />
 * </code>
 *
 * <output>
 * <a class="phone" href="+498515684325" title="my title">5684325</a>
 * </output>
 *
 */

class PhonelinkViewHelper extends AbstractViewHelper {

  /**
   * As this ViewHelper renders HTML, the output must not be escaped.
   *
   * @var bool
   */
  protected $escapeOutput = false;

  /**
   * Create phone link
   *
   * @param string $number : telephone number
   * @param string $title : link title attribute / string
   * @param string $countrycode : default country code, "49" for Germany
   * @param string $areacode : default area code, without leading zero, "851" for city Passau
   * @param string $class : CSS class name
   *
   * @return string HTML code with a link to the telephone number
   */
  public function render($number, $title = false, $countrycode = false, $areacode = false, $class = false) {
    $title = $title ? $title : "Reachable by phone at: {$number}";
    $class = $class ? $class : "";

    return "<a ".$this->setCSSClass($class)." href='tel:"
      . $this->format_telephone_number_rfc3966($number, $countrycode, $areacode)
      . "' title='{$title}' itemprop='telephone'>{$number}</a>";
  }

  /**
   *
   * @param string $class : CSS class name
   *
   * @return string class="classname"
   *
   */
  public function setCSSClass($class) {
    if($class) {
      return "class='{$class}'";
    }
  }

  /**
   * Convert a telephone number into a full-featured RFC 3966 telephone number
   *
   * @param string $number : telephone number
   * @param string $countrycode : default country code, "49" for Germany
   * @param string $areacode : default area code, without leading zero
   *
   * @return string Full RFC 3966-compatible telephone number
   *
   * @author Christian Hackl <hackl.chris@googlemail.com>
   * @originalCode Christian Weiske <cweiske@cweiske.de> // was written for the old tt_address extension
   */
  public function format_telephone_number_rfc3966($number, $countrycode = false, $areacode = false) {
    $countrycode = $countrycode ? $countrycode : "49"; // Germany
    $areacode = $areacode ? $areacode : "851"; // City Passau

    $num = preg_replace('#[^+0-9]#', '', $number);
    if (substr($num, 0, 1) === '+') {
      //full telephone number
      $tel = $num;
    } else if (substr($num, 0, 2) === '00') {
      //full number with country code, but 00 instead of +
      $tel = '+' . substr($num, 2);
    } else if (substr($num, 0, 1) === '0') {
      //full number without country code
      $tel = '+' . $countrycode . substr($num, 1);
    } else {
      //partial number, no country or area code
      $tel = '+' . $countrycode . $areacode . $num;
    }

    return $tel;
  }
}

[BastianBalthasarBux]

hmm, there are people which are living outside of passau, even outside of germany (so do I ;)). so this advantage will be always limited to just 'some' people. and how should i do the backend evaluation then? right now it's pretty perfect by just limiting to numbers and a +.

But in general the idea with the viewhelper sounds interesting. I could also imagine further enhancements with the regex, replacing automagically two preceeding zeros by a plus, adding a plus in front if not there, removing plusses everywhere else than preceeding ...etc. With the viewhelper it could be possible e.g. to use the countrycode from static_info_tables. not sure if they are in. but if so, the countrycode will be added under the hood if you select the country from the dropdown (which is not there ATM). Further more, I could then just limit the input to only numbers and spaces, and removing them only for the link. oh no, that won't work. we have fax, mobile and phone. not likely but maybe possible to have three different countrycodes ...

hmm, i will think about it. maybe i could just add spaces to the evalution and go all the way with your viewhelper. but i won't add defaults, i think, as mentioned: only possible for 'some'. but if i add defaults, i would add defaults which are valid for as many people as possible. which leads directly to china. ;) (just kidding)

[Teisi]

Oh yea china... :D

Sounds great, would be nice to had a option like this.

[Teisi]

I've been a bit concerned with it - and read about countrys without area codes and so on...

By one phone number field (varchar): We can only use something like regex to allow only numbers, -,+,(), and so on.

This is the best regex i found: (but without beginning e.g.: 0049, i don't know how to add this) In the viewhelper we can look at the given number and if a country code is given, we can wrap the number with a link - so the viewhelper dont generate a default value. You can test it here: https://regexr.com/ /^(?:\+?(\d{1,3}))?([-. (]*(\d{3})[-. )]*)?((\d{3})[-. ]*(\d{2,4})(?:[-.x ]*(\d+))?)\s*$/gm (no match in the e.g. text of the link above because no whitespace allowed as first letter...)

this works: +49 (0) 65468 5 +1-(800)-123-4567 +7 555 1234567 +7(926)1234567 (926) 1234567 +79261234567 926 1234567 9261234567 1234567 123-4567 123-89-01 495 1234567 469 123 45 67 89261234567 8 (926) 1234567 926.123.4567 415-555-1234 650-555-2345 (416)555-3456 202 555 4567 4035555678 1 416 555 9292

if you want to cover as much as possible and safe as possible, we have to split the phone number in 3 fields country code / area code / actual number. Then we can do with it what we want.

But styling must be done with js if you want things like "+49 (0) 851-6585-26.."

So i think the first one is the better option. I mean we should not format the input but rather pretend what the input field allows

Or what do you think?

[BastianBalthasarBux]

No! No (0) in db, IMHO and also no / and - or . In the end this is IMHO bad behaviour when formatting telephone numbers. they are also not linkable anymore. you cannot even copy-paste on your phone without editing before dialing. I cannot tell you, how much i hate these people crippling my phones functionality by their f*** $%!@!!%ۤ stupid dumbness ... I could rip my face off! [ They write things like: +43 (0)512/123 123 - 0 and they vary each time with all the special signs, removing + in favour of 00 e.g.] (Sorry, heartbeat rate went up "a bit" ... ;))

While I could see some advantages of splitted fields, I am not completely convinced about it yet. Think of all the existing installations and further more think also of all the csv files getting imported. I accept the wish for spaces, that makes sense IMHO. It is also easy to remove them for the link.

Conclusio: I see two valid options for me:

1. keep it, as it is but add whitespaces to be allowed (easy to implement).
2. do something more complex like we did for the name-field some ages ago. Which basically means: split the fileds up and do something backwards-compatible. Means we need to add at least 3 fields for each number (fax, mobile, telephone), that's 9 additional fields in summary. The most important thing will be the backwards-compatibility, which won't be a real 'backwards' compatibility, as we need to keep it e.g. for imports where we (or the user) cannot split up.

[BastianBalthasarBux]

With that commit 3bcdbd605fc6cffe2c3b03d1c4fe810b90b4124e whitespaces are now allowed for telephonenumbers. Additionally there has been introduced a new viewhelper "spaceless", which removes all whitespaces from a given string. That was needed to provide RFC-conform tel: links in the frontend, as we now have whitespaces in the database, which is not allowed for values in href="" ... (works most of the time, but could cause weird behaviour in special circumstances ...)