Module Phone Number Fieldtype

[adrian]

@Roman Schmitz - just wanted to let you know that I have committed a new version to Github that fixes your issue, as well as updates the module in several ways for newer PW versions.

Please let me know if you have any problems with the new version.

[Roman Schmitz]

Hi @adrian - thank you for your quick reply.

I have changed the line and now everything works as expected.

I'm very excited!

[adrian]

1 minute ago, Roman Schmitz said:

I have changed the line and now everything works as expected.

 

Please see my second post - I have updated the module with that fix (actually done differently), as well as some other improvements / updates. I would recommend grabbing the latest version of the module.

Cheers,
Adrian

[Roman Schmitz]

2 minutes ago, adrian said:

Please see my second post - I have updated the module with that fix (actually done differently), as well as some other improvements / updates. I would recommend grabbing the latest version of the module.

Cheers,
Adrian

I missed the second post. Now I have the new version installed and everything works great.

Thanks again for the quick response.

[Arcturus]

Hi Adrian,

I'm having some issues getting the proper output formatting with PW 3.0.61 and the following custom format option:

{[phoneAreaCode]-}{[phoneNumber,0,3]-}{[phoneNumber,4,4]} /* Local North America: 111-111-1111 */

The dropdown outputs my example numbers correctly (555-555-5555), both the module and my phone-based field show the correct format chosen, and on the data entry side, I'm getting Area Code and Number fields in the same box which makes sense. However, when I go to output this field on the front end...

/* imagine the entered data is 416 7773333 and the desired output is 416-777-3333 */

echo $user->cell_phone; /* returns 7773333 */
echo $user->cell_phone->formattedNumber; /* returns nothing, as does the 'un' variant */
echo $user->cell_phone->area_code.$user->cell_phone->number; /* returns 4167773333 */

I could string manipulate the last into what I need, but that would seem to defeat the purpose of the module. Is this only intended to work with $page based references?

[adrian]

Hi @Arcturus - sorry for such a delayed response - I am just back from an extended time away from my computer.

I can't imagine why it's not working for you, unless you are entering the entire "416 7773333" in the main number sub field. The 416 area code needs to be entered in the area code subfield.

Could you please confirm how you are entering things and also the settings for the "cell_phone" field with some screenshots so I can help you diagnose?

[Arcturus]

No worries Adrian, I'll see if I can circle back to that project and investigate next week.

[mel47]

Hi,

Does someone solve or found a work-around for problematic error when used in FormBuilder?

Thanks

[adrian]

Hi @mel47 - thanks for raising the issue here, but let's continue it in the FormBuilder thread where we will get more of Ryan's input

 

[Torsten Baldes]

Thanks for the module!

Is there a way to set the contents of this field via the processwire api?
I'd like to import a large chunk of contacts and I'm using this fieldtype to store the phone numbers.

Thanks!

[adrian]

16 hours ago, Torsten Baldes said:

Is there a way to set the contents of this field via the processwire api?
I'd like to import a large chunk of contacts and I'm using this fieldtype to store the phone numbers.

Of course:

$page->of(false);
$page->phone->country = '1';
$page->phone->area_code = '123';
$page->phone->number = '4567890';
$page->phone->extension = '987';
$page->save('phone');

 

[Juergen]

Hello Adrian,

I want to use the shortcut syntax $page->fieldname->formattedNumber on a file outside of the template folder (in my case a simple template which will be loaded via an Ajax call). But this  doesnt work!

In opposition $page->fieldname as standalone works. So the formatting object "formattedNumber" is not callable outside of the template folder. The file where I want to use it is located in /site/ajax/nameofthefile.php (outside of the template folder). I use the bootstrapping technique to get field values outside of PW templates folder.

Is there a possiblility to load the module inside this template file so I can use formatted and unformatted numbers?

Best regards

[adrian]

Hi @Juergen - it's all about output formatting. It is off by default when bootstrapping.

So just do this:

$p = $pages->get(n);
$p->of(true);
$p->fieldname->formattedNumber // OR $p->fieldname

Remember that calling $p->fieldname will actually return a formatted version by default - you don't need to explicitly specify ->formattedNumber

If you don't want to turn on output formatting for the entire response, you can also use PW's getFormatted like this:

$p->getFormatted('fieldname');

 

[adrian]

@mel47 - I just committed the version that supports FormBuilder so you can now start using this version again.

[Juergen]

8 hours ago, adrian said:

It is off by default when bootstrapping

Thank you. I didnt know this. Now it works

[godmok]

Hi @adrian,

I got an error on line #186 in InputfieldPhone.module. Error comes up on a created phone field.

Fixed it by using double underscore. Wrote an issue in github, too.

Error (with single underscore):

$f->description = _('Whether to ask for extension when entering phone numbers.', __FILE__);

Fix (double underscore):

$f->description = __('Whether to ask for extension when entering phone numbers.', __FILE__);

 

I got two other issues, too, but can't figure it out how that works: The phone field is in a user template called "person" (have multiple user templates), and if I set a zero at the beginning of the area code, then this zero will not be saved, as long as I write another number to it (after or before the zero). Here some examples:

• Number 123 -> change to 0123 -> after save: 123
• Number 123 -> change to 01123 -> after save: 01123 -> change to 0123 -> after save: 01123
• Number 0123 -> change to 00123 -> after save: 0123
• Number 0123 -> change to 10123 -> after save: 10123
• Number 123 -> change to 0456 -> after save: 0456 -> change to 0123 -> after save: 0123

Best solution for now is to delete the field and set it new.  Anther Solution is to change the numbers to something else then change it back.

The output on the frontend wasn't changed after the profile update, I had to save/update(select output format) the phone field again, so the output was right again. That was no caching problem, or at least no normal one.

Edited January 15, 2018 by godmok
added two additional issues

[adrian]

Thanks for those reports @godmok - should all be fixed in the latest version, although I didn't quite understand

5 hours ago, godmok said:

The output on the frontend wasn't changed after the profile update

so could you please check that is working now as well. I assume it was related to the leading zero issue which is now fixed.

[godmok]

Hi @adrian, sorry for being late. Now the field works like it should.

I was just questioning myself if it would be possible to create own formated numbers and output them. I use something like this on the field input: 49 0123 456 789. On the output I remove the zero from 0123 if there is one. Then in the frontend there is a link with "tel:+" and I can't use the unformatted number, because the number is wrong. Output unformatted output: 490123456789. This should be the own created output format: 49123456789. Best would be formated as +49123456789.

In the field settings I have set the format with removing the first number, but how can I get this self made output format easy into the frontend? I have created a function for that, but it would be nice to have individual output format names like: $phone->fomatedNumberNoAreaLeadingZero (fomatedNumberNoAreaLeadingZero would be my own set name in the settings, as example), and the output will be from the settings.

Would be nice

[adrian]

3 hours ago, godmok said:

I was just questioning myself if it would be possible to create own formated numbers and output them.

In the module settings you can create your own format. Take a look at the Australia examples - the one with the country code has no leading zero for the area code. My initial suggestion to you would be to create your format based on that. I guess the contingency I never implemented is when you want to be able to call different formats for the same phone field.

My initial thought for adding this is to allow you to call the format based on the name of the format in the commented part. So for example if you created a format like this:

+1 (23) 456-7890 x321 /* My No Leading Zero With Country: +1 (11) 111-1111 x111 */

you would be able to call it via the API like this:

$page->phone->formatted('MyNoLeadingZeroWithCountry');

That way you could create whatever custom formats you need, name them how you want, and call multiple versions on the same field because these wouldn't rely on the format chosen either in the module settings or the field settings.

Does this sound ok?

[godmok]

Sounds good for me Would definitely use it like this!

I tested the field again and changed the fieldtype settings for the "Phone Output Format" under "Modules" -> "FieldtypePhone" and see there, again problems came up.

This are my Output Format Options:

{+[phoneCountry] }{([phoneAreaCode]) }{[phoneNumber,0,3]-}{[phoneNumber,3,4]}{ x[phoneExtension]} /* Standard North America: +1 (111) 111-1111 x111 */
{+[phoneCountry] }{([phoneAreaCode]) }{[phoneNumber]}{ x[phoneExtension]} /* Alternate North America: +1 (111) 1111111 x111 */
{+[phoneCountry]-}{[phoneAreaCode]-}{[phoneNumber,0,3]-}{[phoneNumber,3,4]}{ x[phoneExtension]} /* Alternate North America: +1-111-111-1111 x111 */
{+[phoneCountry]-}{[phoneAreaCode]-}{[phoneNumber]}{ x[phoneExtension]} /* Alternate North America: +1-111-1111111 x111 */
{([phoneAreaCode,0,2]) }{[phoneNumber,0,4] }{ [phoneNumber,4,4]}{ x[phoneExtension]} /* Standard Australia without country code and with leading zero for area code: (01) 1111 1111 x111 */
{+[phoneCountry] }{([phoneAreaCode,1,1]) }{[phoneNumber,0,4] }{ [phoneNumber,4,4]}{ x[phoneExtension]} /* International Australia with country code and without leading zero for area code: +1 (1) 1111 1111 x111 */

{+[phoneCountry] }{([phoneAreaCode,1,6]) }{[phoneNumber,0,3] }{ [phoneNumber,3,3]}{ [phoneNumber,6,3]}{ [phoneNumber,9,3]}{ - [phoneExtension]} /* International phone number with country code and without leading zero for area code: +49 (111) 123 456 789 012 - 111 */

I have set a line between your examples and mine (last line). I can select the format without a problem, but:

• If I delete the line break between, then the selection will not change but has as first option "none" (normally there would be the unformatted version). I would suggest to ignore such empty line breaks in the Format Options textarea, but still have the possibility to set them for groups.
• If I change let's say "phoneNumber,9,3" to "phoneNumber,9,2" in my code (with or without line break), then my format selection is lost and set to unformatted (or "none" as it is first option). Additionally any change in the Format Options field has changed the created field under "Setup" -> "Fields", and there it is set to unformatted/first option. It happens with any changes on the options (adding/removing a block and so on). As I see the <option value=""> under "Fields" uses the Format Option as the value but then loses it after a change.
  And: the frontpage output is still on the last Output Format Option, means no changes were updated on the frontend at all. It won't change as long as I save the field under "Fields" again with the right Format Option selected. That is OK, but then you have to know that you have to update all fields with this selected option again :/

Hope this helps somehow...

[adrian]

@godmok - obviously an easy fix to ignore blank lines. The issue of the format not being updated is a little trickier - currently the selected format is stored by the format "code", rather than by a name, so changing the definition of a format won't update the format stored for a field. I should probably store formats by their "name" so the current definition for a format is called each time. I think this would be a good improvement for this module and would also be inline with your request to be able to call the format directly. The catch is making sure I don't break existing sites using this module, so I'll have to make this change with that in mind.

I'll see what I can do.

[szabesz]

48 minutes ago, adrian said:

I'll see what I can do.

I am about to use this module too (for the first time). The discussed improvements do sound good. Thanks in advance, Adrien!

[adrian]

@godmok and @szabesz - well that took way too much time

It's very rough, but please test the new version on the dev branch: https://github.com/adrianbj/FieldtypePhone/tree/dev

This new version has lots of breaking changes, so please don't update an existing site. You'll need to uninstall and reinstall to get the new format for the default formats to show. You could I guess copy/paste them in from the module code to that field if you have data already that you can't lose.

Format options now have a proper name associated with them, so if you change the pattern for a format, it should update the output everywhere. Also, you can now see exactly how each format will look based on the pattern, rather than you having to enter that in a comment at the end.

 

When defining formats, follow this format. The category headings are optional. The key things is: name | pattern

Now you can also call these formats separately from the API regardless of what the selected output format is. You can call like this:

$page->phone->australiaWithCountryAreaCodeNoLeadingZero

 

[godmok]

This works! tried it on a development site and will now install the new version of it to live.

Update: worked on live site without problems after updating Phone Format Output and my phone field in admin and template file.

[adrian]

@godmok, @szabesz and @mel47 - could you please try the latest version on the dev branch. I had to rejig a few things to get this new version to also work with Form Builder.

@mel47 - please read my previous post above regarding the breaking changes in this new version. I'll be making this the master version once I have confirmation from you guys that you aren't seeing any problems. I don't like introducing breaking changes, but in this case it was necessary to allow more flexibility for calling custom outputs via the API.

Thanks!