[policy, no patch] Remove Telephone module from core

I was curious and compiled some issue queue statistics for telephone module.

Telephone has had a total of 26 issues in its life span in Drupal core as of 2022.02.25:

12 bugs. 4 fixed, 4 closed, 1 postponed, 3 open.
11 tasks. 4 fixed, 6 closed, 1 open.
2 feature requests. 1 fixed, 1 closed (duplicate).
1 support request. 1 closed (works as designed).
Of the 26 issues, 1 critical issue, 1 major issue (duplicate).

This is quite a minimal module as #2 makes clear, but it's also not clear what the core use-case for it is except for increasing the number of core field types.

Having said that:

I went to compare telephone module usage with address in contrib, since they seem pretty related, and whether there was any dependency (there isn't).

This involved double checking the usage on #3158669: [policy, no patch] By default deprecate non-experimental modules that are used by less 5% of sites before the next major version, and it actually says over 80k installs and 24% of sites as of 2020?

telephone,83447,23.65%

Address module has 75k installs which is comparable, makes sense that sites would tend to use them together.

So there might be a reason to remove it apart from core usage (like not being used in either standard or Umami), but it's quite a lot higher than 5% usage.

Does #3 not then suggest that Telephone should not be removed, that this should be closed with "won't fix"?

@DamienMcKenna - yeah I think so. 25% is a lot of sites, and it's a very simple module without a high maintenance burden compared to most others in core.

I think we might want to either open a follow-up or repurpose this issue to see if we want to enable telephone in the standard profile or Umami though. Even if it's to make a concrete decision that it shouldn't be in either of those either.

+1 for keeping as part of Drupal core.

90% of our Drupal 8+ projects use the Telephone field.

This module is unloved and installed on less than 5% of sites according to #3158669

#3158669: [policy, no patch] By default deprecate non-experimental modules that are used by less 5% of sites before the next major version is not resolved yet. So that we should not be guided by it.

The issue summary is incorrect in its suggestion that the module is used on less than 5% of sites, so I'm going to take the leap and close this issue as "won't fix".

Removing the product manager tag. I agree telephone looks like a good one to keep in core. It is pretty minimal and does not have interdepenencies that would make it a red flag that it does not have a dedicated maintainer.

In a slack discussion about #3482705: Allow storing telephone number in E164 format catch suggested this be re-opened. He said that originally having field types in core meant people didn't have to find and download them. However, now with Project Browser and recipes those reasons are not so important.

Following

I originally asked about deprecating this module because I feel most that use it have to use a contributed module like telephone_formatter to get it to work for them. Could be wrong buts been my experience

We don't have many issues open against telephone, but #3482705: Allow storing telephone number in E164 format would require either providing two telephone field types in one module to choose from (very confusing for UX) or hiding the current one and showing the new one with a possible migration path (potentially complex to implement), or moving the current field type to contrib and adding a the new one to core (also pretty complex). It's probably as much code to add or more than the current module has in total.

Given all of that, the previous assessment that telephone is low maintenance doesn't really hold any longer so I think this is worth looking at again. The fact that telephone formatter as 13,000 users also suggests that keeping telephone in core is not stopping people from having to add contrib modules to use it - potentially a contrib version could consolidate some of these things (the new storage format, validation, formatter etc.). I don't think this is used by Drupal CMS so trying to handle all of this in core doesn't seem right either.

Wanted to bump this again about potentially removing in D12 if that window isn’t closed?

The window isn't closed, we deprecate modules up to the last minute because it's not disruptive from an API point of view (and it's a lot of work that's easier to do closer to a major release). We do need a product decision here though.

I think its not an 80% use case module. The general consensus earlier was that it is little maintenance but looks like its not quite true. Quoting the other issue:

One of the biggest challenges with the current Telephone module is that it's just a glorified textfield. It has no option to normalize the telephone number - either for the purpose of validation or formatting.

I don't think its worth doing that investment in core given it is not an 80% use case AFAIS. Removing tag as a product manager.

One thing that came up in the slack discussion but not explicitly here, was that https://www.drupal.org/project/telephone_validation has about 13,000 installs, which suggests that core shipping the telephone module isn't preventing people from having to install contrib modules to actually use it. This is unlike a lot of field types that ship with core and 'just work'.

Stephen would you be prepared to maintain the contrib version?

Sure no problem.

Also did a small search locally about how hard it would be to remove and most references in our tests seem to be in migrations and uninstall/re-install tests.

Counterpoint: I think there is a discoverability issue here with removing it (or any field module) from core until Package Manager is fully stable and in Standard to do its thing. So I would suggest keeping it in core for one additional major.

If we wait to remove this in Drupal 13, then we'll be supporting it in core until 2030. Given we're not going to integrate https://www.drupal.org/project/telephone_validation into core when we know the module will be moved out, or fix issues like #3482705: Allow storing telephone number in E164 format in core either, then having it in core makes it harder to consolidate functionality into one actual module that does what you'd expect.

Even if project browser isn't in core yet, the default install experience has already moved to Drupal CMS which does have it. The drupal_cms_person recipe installs telephone (because it uses it), but the base recipe does not.

This is actually a policy issue. If this is agreed to work will be done in other issues, https://www.drupal.org/about/core/policies/core-change-policies/how-to-d...

My perspective remains that basic, low-maintenance field types always belong in core because they provide an easy data model platform. 2030 (while a scary number) is fine if we only have to fix a couple bugs a minor for it, really.

Edit: I forgot about #12. Sorry. :)

Anyway, entering a telephone number that validates internationally is a part of almost every website I use, so the whole premise that this is not 80% is off to me. :)

Given we're not going to integrate https://www.drupal.org/project/telephone_validation into core when we know the module will be moved out, or fix issues like #3482705: Allow storing telephone number in E164 format in core either,

Why not fix them in core though?

@xjm telephone has one maintainer in core, @smustgrave, and he thinks it should move to contrib.

#3482705: Allow storing telephone number in E164 format would rely on a third party js and/or PHP library which would become a production dependency of core for an optional module.

It would also mean having two telephone fields in core - one for the text format and one for e164, unless we moved e164 in and text out but then we'd still be moving more or less all of the current code to contrib then.

So @xjm brought up another idea in slack what if we folded in all or parts of telephone_validation, telephone_formatter, or other highly needed contrib modules around telephone.

1. Removed telephone from core
2. Keep it but fold in additional functionality to make it more useful

Consensus though was one or the other should happen.

Posting this Slack note from @catch here too which elaborates on his comment in #25

https://www.drupal.org/project/telephone_international_widget uses google's libphonenumber as does https://www.drupal.org/project/telephone_validation and it's the sugggestion in https://www.drupal.org/project/drupal/issues/3482705. js only. If we wanted PHP validation, there is a PHP port https://github.com/giggsey/libphonenumber-for-php on github.

We can't selectively add core dependencies based on whether modules are enabled or not, so this would be top level dependencies in package.json/composer.json

With #1797438: HTML5 validation is preventing form submit and not fully accessible in, even assuming that a telephone field only needed to support one national format, the pattern attribute (e.g. pattern="[0-9]{3}-[0-9]{3}-[0-9]{4}") on the <tel> element will not be validated when the <form> is set to novalidate, so external dependencies for phone validation seem to be even more necessary.

+1 for removal from core.

+1 for removal and letting it prosper in contrib. A good telephone field module would include both validation and formatting. Realistically you need libphonenumber or something similar to achieve this, and as mentioned above we don't want this as a core dependency if telephone numbers are not in the 80% use case.

lets do it! What's next steps?

Should be super simple since it's not in any fixtures, themes, or profiles.

There are 6 tests outside the module that had to update which I'm starting over in #3594057: Remove/replace any tests using telephone

Understand we need the METAs but not sure if anyone can make those?

@smustgrave: https://www.drupal.org/about/core/policies/core-change-policies/how-to-d... has the process explained and issue templates linked to use :)

The release managers discussed this and we all agree to the removal of telephone from core. Of us, xjm had the most reservations, as expressed in the her comments here. She would also like to have a "better telephone module" in core, say if one was available for D13 or D14.

Therefor, I am removing the tag and setting this to fixed.

I have updated credit.

oops, forgot to update the meta data.

Is there a contrib Telephone module (moved from core)?

@xmacinfo: that is where it will go in the middle of the whole deprecation / removal process.

Was there a change record for this?

@chi: this is a [policy, no patch] issue, the actual work is happening in #3594196: [meta] Tasks to deprecate the Telephone module.