Issue confirmed.

System information

3.8.3-dev
Multilanguage Site
macOS Sierra, 10.12.6
Firefox 56 (64-bit)

MAMP 4.1.1

• PHP 7.0.15
• MySQLi 5.6.35

The relevant code is here

Reading that it looks like the expected behaviour but I really cant tell

So as I see in code:

@param   integer  $number       The integers in a phone number with dot separated country code
	 *                                 ccc.nnnnnnn where ccc represents country code and nnn represents the local number.

How we should know about it? Where is documentation? In different countries phone nubmers write different. We for example don't use dots in phone number

So how I must to know in which format I need to write phone number if it's nowhere written... Only in code! Very "user-friendly"...

Reading the code it looks like it is an official International Telephone specification. However I agree that it is not a format that would be used in the UK either. To be honest what I would do is just to exclude the filter. Its not needed and it doesnt really help

I am going to close this. The filter is working as intended. Its just not very useful

It seems the code in https://github.com/joomla/joomla-cms/blob/54eb5d8cea29b064c2ad2122e15e71d478c60b01/libraries/cms/html/tel.php#L34 is not applied in this case.

We have there

	public static function tel($number, $displayplan)
	{
		$number = explode('.', $number);
		$countrycode = $number[0];
		$number = $number[1];
		if ($displayplan === 'ITU-T' || $displayplan === 'International' || $displayplan === 'int' || $displayplan === 'missdn' || $displayplan == null)
		{
			$display[0] = '+';
			$display[1] = $countrycode;
			$display[2] = ' ';
			$display[3] = implode(str_split($number, 2), ' ');
		}

for the default format ITU-T

which should give, if entered as
33.4577729624
the following result
+33 4577729624

As it is not the case (tested here: we get 33.4577729624), I guess we do have an issue with that filter.

I suggest to reopen.

I do agree with infograf768.
On top of that, why having a not useful filter??

In fact, issue may come from
https://github.com/joomla/joomla-cms/blob/staging/libraries/src/Form/Form.php#L1466-L1544

The result does not come from public static function tel() as stated above as I can't find where this method is used in core.

I'm reopening this as the filter is not only not working but gives wrong results (3.9.20 / staging)

Looks like, unless someone totally rewrites that code, that we should take off the Telephone filter from these files:

/plugins/fields/repeatable/params/repeatable.xml:63: 									value="tel">JLIB_FILTER_PARAMS_TEL</option>
/plugins/fields/text/params/text.xml:21: 				<option value="tel">JLIB_FILTER_PARAMS_TEL</option>
/plugins/fields/text/text.xml:40: 					<option value="tel">JLIB_FILTER_PARAMS_TEL</option>
/plugins/fields/textarea/params/textarea.xml:47: 				<option value="tel">JLIB_FILTER_PARAMS_TEL</option>
/plugins/fields/textarea/textarea.xml:68: 					<option value="tel">JLIB_FILTER_PARAMS_TEL</option>

Not sure why you tagged me, but if the filter is not correct. Then at least remove it in com_fields. Keep in mind about the upgrade of the existing filters, need to be unset in the existing fields.

@laoneo
I tagged you because you introduced these filters in fields a long while ago #14403.
The filter is defined in JForm. I have seen nowhere in code the use of filter="tel"
Contact is using a simple text field.

No idea where I would unset the filter (after deleting the option in the plugins). Can you help?

Deleting the option would be enough, more difficult is the update of fields which have this filter set in the params on existing sites.

I doubt anybody has ever used that filter, taking into account that it is really broken, but would it make sense to add in an sql update some code that would just change filter="tel" by filter="text" in every occurrence of fieldparams in db fields table?

Here the export of such a field.
(25, 3287, 'com_content.article', 0, 'Telephone field', 'telephone-field', 'Telephone field', '', 'text', '', '', 1, 0, 800, '2020-07-19 14:59:22', 0, '{\"hint\":\"\",\"class\":\"\",\"label_class\":\"\",\"show_on\":\"\",\"render_class\":\"\",\"showlabel\":\"1\",\"label_render_class\":\"\",\"display\":\"2\",\"layout\":\"\",\"display_readonly\":\"2\"}', '{\"filter\":\"tel\",\"maxlength\":\"\"}', '*', '2020-07-19 10:13:47', 800, '0000-00-00 00:00:00', 0, 1);

By using

UPDATE `#__fields` SET `fieldparams` = REPLACE(`fieldparams`, '"filter":"tel"', '"filter":"text"');

we correct db.

What do you think?

Looks good for me. Perhaps you want to add in the update statement a where clause "type='text'".

By using

UPDATE `#__fields` SET `fieldparams` = REPLACE(`fieldparams`, '"filter":"tel"', '"filter":"text"');

we correct db.

What do you think?

@infograf768 The replacement should work and be safe, since both the search string and the replace string contain the complete name value pair, including the double quotes. We only had problems in past when this was not the case so that substrings were matching, too, where it was not desired.

But maybe the context column should be limited to certain values so that we cover only fields used for the core, i.e. add a

 WHERE `context` IN ('com_content.article', ...)

to the update statement?

Please do NOT add the context clause as it belongs to all fields, not only the ones from articles. But the filter is only applied to text fields, so you can limit it there.

Ok, so a

WHERE `type` = 'text'

should be added.

In fact we also have for repeatable/textarea another format. therefore

`WHERE `type` = 'text'`

is not enough.
{"fields":{"fields0":{"fieldname":"a form fields name","fieldtype":"textarea","fieldfilter":"tel"}}}

Sure, then its an IN list with a few types.

@richard67
for sql update:

3 types concerned
text
textarea
repeatable

2 formats of fieldparams
filter="tel" => filter="text"
fieldfilter="tel" => fieldfilter="text"

Option to delete in 5 files

/plugins/fields/repeatable/params/repeatable.xml:63: 									value="tel">JLIB_FILTER_PARAMS_TEL</option>
/plugins/fields/text/params/text.xml:21: 				<option value="tel">JLIB_FILTER_PARAMS_TEL</option>
/plugins/fields/text/text.xml:40: 					<option value="tel">JLIB_FILTER_PARAMS_TEL</option>
/plugins/fields/textarea/params/textarea.xml:47: 				<option value="tel">JLIB_FILTER_PARAMS_TEL</option>
/plugins/fields/textarea/textarea.xml:68: 					<option value="tel">JLIB_FILTER_PARAMS_TEL</option>

Can you do the patch? I'm not familiar with IN

@infograf768 The 2 formats "filter" and "fieldfilter" can happen with all the 3 types?

Looks like fieldfilter is only for repeatable

/plugins/fields/repeatable/params/repeatable.xml:34: 								name="fieldfilter"
/plugins/fields/repeatable/repeatable.php:69: 			if (isset($formField->fieldfilter))
/plugins/fields/repeatable/repeatable.php:71: 				$child->addAttribute('filter', $formField->fieldfilter);

Is filter then only for text and textarea?

It looks like indeed

UPDATE `#__fields` SET `fieldparams` = REPLACE(`fieldparams`, '"filter":"tel"', '"filter":"text"') WHERE `type` IN ('text', 'textarea');
UPDATE `#__fields` SET `fieldparams` = REPLACE(`fieldparams`, '"fieldfilter":"tel"', '"fieldfilter":"text"') WHERE `type` = 'repeatable';

Does that look right? If yes, please do you do the PR, @infograf768 ... I have too little time now.

OK, will do.

Closing as we have patch #30142

Needs sql update for postgresql and sqlazure