- Issue created by @w01f
- π§πͺBelgium matthijs
I started this module because because those two other modules were kinda broken/dead at that time (no clue what their current state is) + it felt kinda odd having two modules for these features.
Joining forces might be an option, but the most logical scenario would be that the other modules are deprecated and an upgrade path is provided. WDYT? Did you open an issue on the other 2 modules as well?
- πΊπΈUnited States w01f
Okay, created similar issues for both of the other modules - hopefully these can be combined in some way, shape, and form, and it looks like the three interested parties can join forces for one, well supported module!
- π³π΄Norway zaporylie
Hi. The other maintainer here. Could you elaborate what made you believe the other 2 modules are broken/dead? They are minimaly maintained simply because there are no critical issues to be addressed. And they work well on huge projects without much maintainence needed.
If you ever reached out to me regarding these modules, either in person or via issue queue, and I did not reply please accept my apologies. Truth to be told I was caught up in work related tasks to the point I was neglecting the issue queue but the telephone_validation module still has over 8000 installs and the number is constantly growing. Telephone_formatter has considerably smaller user base which to some poit justifies that separating these 2 modules makes sense.
My desired progression here would be to add functionality behind telephone_* suite to core's telephone module. IMHO validation (and perhaps formatting) telephone number stored in telephone field is a basic need that has never been properly addressed by the core, hence all the contrib modules serving the same purpose, yours and mine included.
- π§πͺBelgium matthijs
Just to be clear: I meant when I created this module (3 years ago). At that time there were a few long-standing open issues with pending patches that I needed in all my projects because otherwise the module didn't work (at least not for Belgian numbers). And those patches didn't seem to get committed, even tough they were tested and reviewed by various people.
But I see both your modules have a recent release, so I was obviously wrong! And no need to apologize, we're all aware of how time consuming an issue queue can be. I don't think I ever reached out, I just started this module because I also had the requirement to format phone number in the DB for e.g. searching and exporting (unless I'm mistaken this wasn't/isn't supported by your modules?) and I didn't want to create a patch and had to maintain it for a long time until it got merged.
Anyhow, I agree that core should have at least some basic functionality regarding phone numbers, but I'm afraid this is never gonna happen since this will yet be another library requirement also needing maintenance.
- πΊπΈUnited States w01f
Just to throw fuel on the fire - I also came across this module: https://www.drupal.org/project/phone_number β . As a seasoned Drupal architect and builder, I'm still a bit confused as to the best path/methods forward here to support a number of clients. I can see this being very confusing for someone just getting started, or at least confusing if they're concerned about the "best" manageable and sustainable path forward to implement robust phone functionality.
- πΊπΈUnited States w01f
Created another issue for the phone_number module wondering if we could add in validation, formatting, and obfuscation options there as well - https://www.drupal.org/project/phone_number/issues/3462663 β¨ Additional functionality - validation, formatting, obfuscation Active