Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
When I enter a phone number and I choose UK countrycode, I get the following:
# Notice: Undefined index: #item in gb_formatter_default() (line 81 of \sites\all\modules\cck_phone\includes\phone.gb.inc).
# Notice: Use of undefined constant _uk_phone_rules - assumed '_uk_phone_rules' in gb_formatter_default() (line 86 of \sites\all\modules\cck_phone\includes\phone.gb.inc).
# Warning: preg_match(): Unknown modifier 'p' in gb_formatter_default() (line 86 of \sites\all\modules\cck_phone\includes\phone.gb.inc).
It works ok with US and other numbers.
Comment | File | Size | Author |
---|---|---|---|
#27 | uk_formatting_d6-1008800-27.patch | 3.63 KB | thinkyhead |
#27 | phone.gb_.inc-(D6).zip | 1.62 KB | thinkyhead |
#27 | phone.gb_.inc-(D7).zip | 1.62 KB | thinkyhead |
#25 | uk_formatting-1008800-25.patch | 3.08 KB | thinkyhead |
#24 | uk_formatting-1008800-24.patch | 3.51 KB | thinkyhead |
Comments
Comment #1
Roze-1 CreditAttribution: Roze-1 commentedSame thing here, Problem occurs as with UK
warning: preg_match() [function.preg-match]: Unknown modifier 'p' in /home/mysite/public_html/iceds/sites/all/modules/cck_phone/includes/phone.gb.inc on line 85.
warning: preg_match() [function.preg-match]: Unknown modifier 'p' in /home/mysite/public_html/iceds/sites/all/modules/cck_phone/includes/phone.gb.inc on line 85.
Comment #2
vsailo CreditAttribution: vsailo commentedSame problem. But works with other countries.
Comment #3
BenK CreditAttribution: BenK commentedSubscribing
Comment #4
Tebb CreditAttribution: Tebb commentedSubscribing
Comment #5
Roze-1 CreditAttribution: Roze-1 commentedAny advancement with this issue ?
Comment #6
ckngFixed in dev.
Comment #7
Roze-1 CreditAttribution: Roze-1 commentedProblem persist, Please check the image that i have attached.
Comment #8
Roze-1 CreditAttribution: Roze-1 commentedForgot to Re-open .. And problem persists in dev and 6.x-1.0 version
Comment #9
roball CreditAttribution: roball commentedI can confirm that - with the 6.x-1.0 version - any number put in when "UK (+44)" is selected, will not be displayed, even if country level validation has been disabled. You will just see "+44-".
As a quick workaround, you can edit
gb_formatter_default()
in "includes/phone.gb.inc
":$phone = $cc['code'] . '-' . $item['number'];
or, even better, completely disable the inclusion of the "
phone.gb.inc
" file by renaming it (for example to "phone.gb.inc.X
").Comment #10
Tebb CreditAttribution: Tebb commentedTo clarify: As I understand it this was reported as a D7 issue, so I guess it's probably a D6 and D7 issue.
Comment #11
roball CreditAttribution: roball commentedYes, the bug is in both the latest D7 and D6 releases.
Comment #12
YesCT CreditAttribution: YesCT commentedsubscribing
Comment #13
YesCT CreditAttribution: YesCT commentedI added some dpm in phone.gb.inc
and the dpm($matches) returns an array with
Comment #14
roball CreditAttribution: roball commentedYea, the _uk_phone_rules() regex is the erroneous source.
Comment #15
YesCT CreditAttribution: YesCT commenteduk inc seems to be different from the other inc files in that is specifies the possible patterns as (using a bunch of ORs instead of just one pattern):
http://php.net/manual/en/function.preg-match.php
says "If matches is provided, then it is filled with the results of search. $matches[0] will contain the text that matched the full pattern, $matches[1] will have the text that matched the first captured parenthesized subpattern, and so on. "
And since there are a bunch of parenthesized subpatterns, it returns an array of up to 13 or so elements. The other inc files and this one are trying to set the phone using matches[1] matches[2] and matches[3].
So, I re-wrote it, using an array of possible regular expressions and eliminating the parens around the [0] (which is not desired in the result);
I'm not sure what to return when no match is found.. it actually shouldn't get to that point (if it is validated using gb_validate_number() ). But leaving it to return the $phone like it is, is doing exactly what it was before. So, I'm leaving it that way.
I also took out the dash in the formatted number, and added a space between the country code and the phone number. I looked at a few uk numbers on the web and most seemed to just go with spaces.
Needs testing for cases that will match each of the possible patterns.
Comment #16
YesCT CreditAttribution: YesCT commentedI took off trailing white space and made my comment a sentence.
Also, note that the 4th possible regular expression only has 2 parenthesized subpatterns.
Comment #17
ckngThe patch in #16 looks fine to me.
Please test and review it, set it to RTBC if everything ok, will check back soon.
Comment #18
desrosj CreditAttribution: desrosj commentedPatched and tested, but after patch I see no phone numbers instead of just +44.
Comment #19
roball CreditAttribution: roball commentedThe patch has been created for 6.x, right? So pls test it with the correct branch.
Comment #20
ckngGetting
The last rule do not return a $matches[3];
Number used for test
+44 1231 231111
Comment #21
dddbbb CreditAttribution: dddbbb commentedI'm also getting this problem with UK numbers in the D7 version (Notice: Undefined offset:). Would be happy to test D7 patches if someone can provide them.
Comment #22
nikemen CreditAttribution: nikemen commentedsubscribing
Comment #23
dddbbb CreditAttribution: dddbbb commented@nikemen - Stop subscribing, start following (big blue/grey button at the top right of the page).
Comment #24
thinkyhead CreditAttribution: thinkyhead commentedHere's a patch for the current 7.x-1.x-dev that does everything in the previous (6.x) patch posted in #16. It seems to properly handle the case mentioned in #20. As an additional enhancement, if for some reason the number is not matched by one of the regexes it simply prepends the country code to the raw
$element['number']
value. This at least prevents a blank phone number from coming back, and would be the proper failsafe method.Comment #25
thinkyhead CreditAttribution: thinkyhead commentedThe array regex doesn't seem to be needed as long as the $matches result is handled properly. This patch supersedes the previous one.
Comment #26
dddbbb CreditAttribution: dddbbb commentedThe patch doesn't seem to work. Part of the problem may be that it's pointing at 'includes/phone.gb.inc' which seems incorrect (the directory is called 'include' not 'includes' - no 's'). Even stripping out the unwanted 's's seems to result in errors.
Any chance or rerolling the patch? I'd do it myslelf if I could get it to work :/
Comment #27
thinkyhead CreditAttribution: thinkyhead commented@dixhuit, are you sure you read my comment at #24? That was a patch against the 7.x-1.x-dev branch, which I got directly through git. And the 7.x-1.x branch does indeed use the name 'includes' for the included files folder. In fact, I just downloaded and patched the 6.x-1.x-dev branch, and it likewise uses a directory named 'includes.' So, that patch is attached here. For simplicity I've also attached my patched phone.gb.inc files for each branch.
Comment #28
dddbbb CreditAttribution: dddbbb commentedOops, I may have been using the latest stable release, rather than the dev branch. WIll check again and feedback.
Comment #29
dddbbb CreditAttribution: dddbbb commentedAah. Turns out I was using the 'phone' module (not 'cck_phone'). My bad :/
Comment #30
dddbbb CreditAttribution: dddbbb commentedInstalled cck_phone and sure enough the new phone.gb file seems to fix this issue. Still couldn't get the patch to work but maybe that's just me.
Comment #31
nikemen CreditAttribution: nikemen commentedI've tested the file with 7.x-1.x-dev and it works perfectly.
Comment #32
ckngThanks for the patches, committed to both D6 & D7.
Comment #33
adam_b CreditAttribution: adam_b commentedIs this in the 16 Feb dev version? I'm still getting only a partial display (+44-20 7207). In addition, I still can't enter a UK mobile number.
Comment #34
adam_b CreditAttribution: adam_b commentedOkay, in the 17 Feb dev version (once I'd got rid of #1444442: Fatal error) a regular UK phone number now displays correctly.
But UK mobile numbers don't work at all. As soon as I change the leading number to a 7 (which is the only thing that specifies a mobile number), I get an error:
"70 1234 5678" is not a valid United Kingdom phone number, it should be a 10 digit number like "99 9999 9999", with optional leading "0"
The only way to make it work is to untick the "Enable country level validation" checkbox in the field config.
Comment #35
adam_b CreditAttribution: adam_b commentedSorry, didn't mean to change the status...
Comment #36
Tebb CreditAttribution: Tebb commentedDid I misunderstand?
If as mentioned in #34, this doesn't work for UK mobile numbers, why are we saying it's fixed?
Example:
In the UK: 07912 345678 ==> Internationally: +44 7912 345678
Comment #37
adam_b CreditAttribution: adam_b commentedWell, I'd say the original bug mentioned in the title has been fixed, and this issue is long enough - so I've opened a new one for the UK mobile bug at #1450146: UK mobile phone numbers aren't accepted.
Comment #38
Tebb CreditAttribution: Tebb commentedOK.
Thanks Adam.
Comment #40
g1smd CreditAttribution: g1smd commented> "70 1234 5678" is not a valid United Kingdom phone number"
This isn't a mobile number. It's a premium rate Personal Number.
UK mobile numbers begin 074, 075, 07624, 077, 078, 079 (and will likely also use 073, 072, and 071 in the future).
Additionally, the module doesn't correctly format UK landline 5+5 (e.g. 015395 44777) or 5+4 (e.g. 016977 3555) numbers. Things get a little more complicated in those Mixed Areas (and in ELNS areas).
Mixed areas are those detailed at: http://www.aa-asterisk.org.uk/index.php/Mixed_areas