tel:tel:

We are also seeing the very same effect.. the link is outputting as "tel:tel:+1-310-900-xxxx".

Our page is being shown using views unformatted list, showing fields with the Content: Phone field added.

Thought i'd share as it might not only be related to Display Suite (we do have DD installed as well) but not used for the page where Phone field is shown.

I am also seeing this, and it is not a Display Suite issue. It looks to me as if libphonenumber-for-php was recently modified to add the tel: prefix for the RFC3966 format, as of commit 2447df4655dcbddfab733de392ff077cf3d621e6. The attached patch adds a check to see if the library added a tel: prefix before prepending one manually.

The tel:tel: happens regardless of what formatter is chosen. Does this alter the patch at all?

My patch should work regardless of which field formatter is selected (I'm mostly using National, myself). The patch simply addresses the section of module code that creates the link portion of the hyperlink when the formatter option of "As tel: link" is set to true. The module is passing a hard-coded value of RFC3966 to the libphonenumber-for-php library when it requests the value of the phone number in a suitable format for the link itself. Does that address your question?

This does bring up a slightly larger point though. RFC3966 is a URI scheme (hence the tel:), not simply a phone number display format. However, it appears that the libphonenumber-for-php library didn't properly implement RFC3966 until recently, so the phone module was adding the 'tel:' prefix itself, and thus this bug has begun to manifest.

Since the phone module exposes RFC3966 as a field format to the site builder (in addition to simply using it in conjunction with the "As tel: link" option), this recent change in the library would also potentially impact any users who are rendering their phone numbers using that format. With older versions of libphonenumber-for-php installed, a phone number may have been output as '+41-44-668-1800', where as now it will appear as 'ext:+41-44-668-1800'. This will likely be undesirable for users wanting only the "International, but with all spaces and other separating symbols replaced with a hyphen" aspect of RFC3966. So perhaps a larger discussion is warranted, as far as whether it really makes sense to expose RFC3966 as a field format.

This fixes the issue for me. The tel feature is not usable without this patch, so this should be commited slight fast ;)