Remove Telephone module from core

Created on 25 February 2022, over 3 years ago
Updated 8 April 2025, 4 months ago

Problem/Motivation

No clear use case for inclusion in core.

Steps to reproduce

Proposed resolution

The module is deprecated and moved to contrib.

Remaining tasks

User interface changes

Introduced terminology

API changes

Data model changes

Release notes snippet

🌱 Plan
Status

Active

Version

11.0 πŸ”₯

Component

telephone.module

Created by

πŸ‡¦πŸ‡ΊAustralia griffynh Sydney

Live updates comments and jobs are added and updated live.
  • Needs release manager review

    It is used to alert the release manager core committer(s) that an issue significantly affects the overall technical debt or release timeline of Drupal, and their signoff is needed. See the governance policy draft for more information.

  • Needs product manager review

    It is used to alert the product manager core committer(s) that an issue represents a significant new feature, UI change, or change to the "user experience" of Drupal, and their signoff is needed. If an issue significantly affects the usability of Drupal, use Needs usability review instead (see the governance policy draft for more information).

Sign in to follow issues

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡³πŸ‡ΏNew Zealand quietone

    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.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    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

  • πŸ‡¬πŸ‡§United Kingdom catch

    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.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

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

  • πŸ‡¬πŸ‡§United Kingdom catch

    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.

  • πŸ‡­πŸ‡ΊHungary GΓ‘bor Hojtsy Hungary

    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.

  • πŸ‡¬πŸ‡§United Kingdom catch

    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?

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    Sure no problem.

  • πŸ‡ΊπŸ‡ΈUnited States smustgrave

    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.

  • πŸ‡ΊπŸ‡ΈUnited States xjm

    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.

  • πŸ‡¬πŸ‡§United Kingdom catch

    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.

Production build 0.71.5 2024