Phone field support

Created on 27 May 2023, over 1 year ago
Updated 6 July 2023, about 1 year ago

I'm working on a few sites that should allow users to add a variable number of phone numbers for different extensions or services. Right now I'm handling this by having "phone" as its own Content Type, and then adding to user accounts as an entity reference... which I think is somewhat overkill and am not sure about performance or other backend complexity issues that might be caused.

This module seems like it would be a much cleaner way to implement this. Any chance we could get phone field support. Also noting that we just the telephone_formatter and telephone_validation modules in tandem, though I'm not sure that would cause any issues.

✨ Feature request
Status

Fixed

Version

1.0

Component

Code

Created by

πŸ‡ΊπŸ‡ΈUnited States w01f

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @w01f
  • πŸ‡ΊπŸ‡ΈUnited States apmsooner

    Hey @W01F,

    Totally agree. We need phone field widget and shouldn't be too much effort to make it happen. It's been on my radar as well so thanks for posting the feature request. I'll get a patch up that provides this feature as soon as time permits.

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

    Wow, and awesome - thank you so much and I'm more than willing to guinea pig some test cases, replacing both a multifield email and phone field I'm currently using entire content types for:

    Email
    Label (machine name: field_email_label)
    Email (machine name: field_email)

    Phone
    Label (machine name: field_phone_label)
    Number (machine name: field_phone_number)
    Extension (machine name: field_phone_extension)

    I'll also be able to test the latter with the two other modules I listed above: telephone_formatter and telephone_validation.

    Just for edification as I'm not very knowledgeable about these things, but I'm fairly certain this will be a cleaner approach to these use cases as I think there's a LOT of unnecessary additional config when creating these as content types, but are there any other "good to knows", benefits, or suggestions for implementing?

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

    These modules wouldn't directly be compatible with custom field: telephone_formatter and telephone_validation. The formatter module depends on the core field type of "telephone" so we would have to provide our own version of formatter on the column value of the custom field. The telephone_validation module description seems to possibly work with as a form api property so that one may be possible to conditionally work if that module is enabled... or I could take a look at what its doing and possibly copy the functionality into custom_field and ideally eliminate the need for another module.

    Overall, yes individual fields and content types to handle this in the current way you described is extra config and also a hit to performance. Every drupal field by design is its own table so in this example, those are currently 3 tables to store those values along with the content type that is containing them. A multi-valued custom field would result in a single table with those values stored as columns within the table which eliminates joins and thus is better for performance and storage.

    Phone
    Label (machine name: field_phone_label)
    Number (machine name: field_phone_number)
    Extension (machine name: field_phone_extension)

  • @apmsooner opened merge request.
  • πŸ‡ΊπŸ‡ΈUnited States apmsooner

    @W01F - basic telephone widget support in attached patch. I'm thinking for the other features, an addon module extending this field type might be the best route forward to keep this module light. The widget has basic features similar to textfield supporting prefix/suffix and maxlength. I don't know if thats overkill since the telephone module in core is really basic but give it a try and let me know what you think.

  • Status changed to Needs review over 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States apmsooner
  • πŸ‡ΊπŸ‡ΈUnited States apmsooner
  • Status changed to Fixed about 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States apmsooner
  • Status changed to Fixed about 1 year ago
  • πŸ‡ΊπŸ‡ΈUnited States apmsooner
Production build 0.71.5 2024