Remove Telephone module from core

In a slack discussion about ✨ Allow storing telephone number in E164 format Active 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 ✨ Allow storing telephone number in E164 format Active 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 an 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 ✨ Allow storing telephone number in E164 format Active 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.