Disable this validation when the client chooses the option "I will use my existing domain and update my nameservers".
In our case, when our clients choose that option we want them to be able to use any domain. Since they are not registering them with us, there is no need to validate if we have that tld, or anything.
I know there is a solution here:
https://help.whmcs.com/m/85428/l/1034165-troubleshooting-invalid-domain-name-provided-messagesBut it says that to be able to fix this issue, we have to add either a whois server or a price for each tld. As I have stated before, we don't really care which tld the client chooses, which means that we would have to add a whois server for every possible one (since adding a price is not an option, because we don't want the client to be able to register or transfer the domain) there are hundreds of them...
Thanks.-
3 Comments
Login to post a comment.
Because of this lack of consideration, I have to now add an additional domain TLD for a ZERO FEE (because we don't offer it) for ONE client only who wants to purchase hosting through me but because we don't offer that specific domain TLD for registration we can't set a domain registrar either. Now, this domain TLD will be listed as an available TLD to register for other clients which means some random client might come along now and register this TLD and we will need to tell them AFTERWARDS that we don't offer this TLD for registration and cancel the order and refund them any fees. Not to mention that when they perform an availability search, they now see "The domain is available" as well as "This domain is not available" because there is no registrar set.
Hmmm...MAJOR oversight on this one!
Thanks for your suggestion.
When we implement tighter controls over input, we typically do that 2 reasons:
We've received feedback the current implementation has become too permissive, and companies are having to expend customer service resources fixing the input. We can help companies save money by preventing simple mistakes such as these.
As such we need to have some validation on the domain extension field, and after much consideration, the current hierarchy was finalized as the best combination of validation and user-customisation; domain pricing > tbltlds > whois.json file.
This means that over 1000 different domain extensions can be used out-of-the-box, and more easily added by users via the UI and a simple, persistent file edit.
That said, we can see value in providing more refined error messaging about this error, perhaps something along the lines of "Domain extension not recognized, please contact us to place your order", so will be looking to make that change in the future.