Nominet module - Command syntax error when updating contact details

[Chris74]

Hi I was wondering if anyone else can confirm this is happening for them too?

 

There seems to be a problem with the phone number /country fields when updating contact details for UK domains. WHMCS modifies the phone number to add the country code. This seems to work for saved contacts, but it doesn't work when specifying the info manually.

 

For example, If the main customer profile details contain a country and phone number as follows...

 

United Kingdom

0208123456

 

When you use those primary account details for a domain's contact info, WHMCS will modify the phone number so it says +44.208123456 and modify the country to "GB" instead of "United Kingdom" when submitting to Nominet.

 

But this validation seems to be missing when you enter the details manually and so any update to the phone number will fail. To confirm this.....

 

1. Become a customer with a Nominet domain

2. Edit the contact details for the domain, choosing "Specify custom information below"

3. Enter a normal phone number like 0208123456

4. Submit the form

 

It should result in "Command Syntax Error".

 

The only way to make WHMCS accept the changes, is to enter the country code and phone number as if it had already been modified - i.e GB and +44.208123456

 

So this is the problem my customers are experiencing. In order to update their details, the customer has to create a new contact and use it, instead of entering the details manually.

 

Can anyone else confirm they are having this issue?

[DF-Duncan]

We can confirm the same

[Chris74]

I've had a response from WHMCS on this which is disappointing.

 

Basically, they've said that because the modified +xx.xxxxxx formatted number is pre-filled into the form, all the customer needs to do is edit that, so the problem here is only that the customer is changing the format of the number.

 

I'm not happy with this explanation.

 

Firsty, it is not the customer's fault that WHMCS has changed the formatting of their phone number. When the customer signs up, edits their profile, creates or edits their contacts, they will choose a country from a selection and they will enter their phone number in the standard format that applies to them. This format is retained throughout most of the application.

 

It is important for good interface design, to ensure that you don't change the rules on an end user and it is particularly bad design to ask them to use one format on one page and another format on a different page. To provide the correct experience for the customer, the same conventions and formats should be used throughout the whole application.

 

It stands to reason that the +xx.xxxxxx phone number should never be displayed to the customer at all. They should see their number in the standard format they entered it originally, on all forms. This modified format is only used in the background when sending data via the various API's and in my opinion it is very lazy for the developers to simply pre-fill the form fields with this "background data", instead of using the same conventions as the other forms and displaying their original phone number.

[DF-Duncan]

This said, it should actually show an error that means something to the client, ie Command Syntax Error means nothing to anyone

[Chris74]

This said, it should actually show an error that means something to the client, ie Command Syntax Error means nothing to anyone

 

"Command Syntax Error " is the exact error returned by the Nominet API, which means that Nominet rejected the request because it contained "an improperly formed command element."

 

This often happens if the format of the post code is incorrect - but what's strange here is that Nominet's system doesn't require the phone number to be in the +xx.xxxxxx format, so I'd guess something else is going on here inside WHMCS.

 

Sure, it would be nice to have a correct translation of the error codes in WHMCS, but that's really less important than actually making it work correctly, which is doesn't currently.