techdruid

I have been waiting for two years now for WHMCS to provide a working solution to various inadequacies with their eNom integration. The private registration feature is completely unworkable, premium domains are not supported, and the name spinner feature clashes with the straight up whois search in that a customer has to sift through hundreds of alphabetic tld's before reaching the name spinner suggestions. No followup or action on support tickets or feature requests. I've taken it upon myself to address some of these problems in one fell swoop. But the primary focus is adding support for premium domain names. I would greatly appreciate any feedback on my efforts to make these features work once and for all. While I'm doing it for myself regardless, there may be benefit to sharing/selling and GPLing the code. http://techdruid.com/2016/06/30/whmcs-enom-premium-domains-support/ I've got the code to where the cart is displaying the premium price with a markup applied, and it no longer displays the exhaustive list of alphabetic tld's before displaying the Name Spinner results. There is still much work to be done, but I wanted to request feedback and see what kind of interest there is among others. To see if there are opinions, good or bad, on the approach I'm taking to implement the features. With no access to the core WHMCS code, and no hooks into the domain lookup functions, I'm flying a bit blind.

I'd like to provide this same service. The eNom privacy protection doesn't work very well. If a client signs up for it post-domain-registration, it charges them but then doesn't add the privacy protection. What's the point in charging our customers if the services doesn't even work? So, I'd prefer to just offer this for free and use our information to keep theirs private. Anyone have idea's? The enom.php file is encoded, and there don't appear to be any hooks associated with modifying the contact details. Any implementation of this will be a total hack to the template files and would potentially be outside the scope of the WHMCS internal session security. Ick.

I seem to be able to get around this problem by removing the following CSS setting. In the following file. ./assets/css/bootstrap.min.css .col-xs-10 {float: left;} I'm not a css expert, so I'm not sure why this setting is causing the drop-down to fail. Perhaps I can override this in a custom css file somewhere so I don't need to modify the bootstrap file. I'd sure like to know if anyone else is having this same problem.

This problem is for changing the domain contact information. Is anyone else having this problem where the drop-down is not working when you chose "Use existing account contact"? This seems to be set in the following template file. It has all my contacts in the drop-down when I view the source HTML, but when I click on it, it doesn't drop-down and allow me to choose. I'm not showing any javascript errors in the browsers (Chrome or Firefox) debugging console window either. Seems like there should be *something* when I click on it. I'm at a loss and am having to many issues since upgrading to WHMCS 6.1 that perhaps I'm missing something obvious. clientareadomaincontactinfo.tpl

I've had this same issue. Did you ever find a response on this?

Currently, I'm anticipating that I'm going to be disabling this ID Protection feature from my WHMCS install. It appears that several people have paid for this service and never received it from my company. I've never received any emails alerting me that I need to manually intervene and set this up for anyone. Additionally, when a domain is transferred and ID Protection is enabled, they simply never get what they paid for. Unless someone responds to this thread indicating this problem is fixed, I cannot offer this dysfunctional half/working service to customers.

I'm running WHMCS version 6.0.2 and have enabled the new NameSpinner feature for eNom. The absolute minimum number of domains it allows to suggest is 10. I'd prefer to offer as few as 5, but it doesn't let you choose any less sadly. That is the least of my problems though. While the feature works just fine when you start searching for a domain name from the home page, there appears to be a problem when you search for domain name as part of ordering web hosting. I'm using the comparison order form templates. Basically, before it displays the number of configured suggestions (10 for me) from eNom name spinner, it FIRST displays 25 suggestions from some other source, I'm not entirely sure where. Anyway, it results in the display of 35 total alternative suggestions. I'm guessing that first 25 is coming from the old whois search, rather than the eNom name spinner module as the first 25 are simply finding the first 25 TLD's available for your exact/precise name search. There's no change in the second level domain name suggested for the first 25. Has anyone else experienced this problem? Do you have a fix or workaround to disable those 25 suggestions? I also note that it will display all suggested alternatives EVEN IF your primary desired domain name is available. At this point, I'm considering a hard hack of the template file to limit the number of displayed records. I'd much prefer not to use that as the solution. Because any update to the template from WHMCS will break my changes. Thanks in advance for any suggestions.

Brilliant! That worked. Thank you Brian!!

Hello, I used to have a custom php section when PHP was enabled in the Smarty templates for removing the affiliate menu item for non-affiliates. With the upgrade to WHMCS version 6, php code is disabled by default. I'm inclined to follow the advice and not make PHP calls directly from the smarty templates. So what I'm looking at as an alternative is adding a ClientAreaNavbars hook, and using the "primaryNavbar->removeChild('Affiliates')" option to remove the menu item. However, what I'm struggling with is how do I write the code to determine if the the current user is an affiliate or not? Do I have to custom code getting to the database? Or, are there variables or functions available to me within a hook function where I can grab this information? I tried using the "use Illumiate\Database\Capsule\Manager as Capsule" library, but that doesn't seem to work within the function. I've got the following code to work to remove the menu item for EVERYONE. Now I just need to narrow it down to only remove it for non-affiliates. Any advice would be much appreciated. <?php if (!defined("WHMCS")) die("This file cannot be accessed directly"); function MY_navbar_mods() { $primaryNavbar = Menu::primaryNavbar(); $primaryNavbar->removeChild('Affiliates'); } add_hook("ClientAreaNavbars",1,"MY_navbar_mods"); ?>

Thanks for this script seanie248. It's very helpful. I'm wondering though, do you know if we can use the enom registrar functions to get the registrant email address instead of sending to the account contact? The rules require that we send to the registrant and not the account contact. I was trying to use enom_GetContactDetails(), but that function does not seem to exist. Thanks in advance for any advice. Of course that still doesn't get the sendMessage to send to a specific email address, so I'll probably need to do some hard coding to get the email to use the template and to update the database/log.

Hello Brian, Any word back on the status of .country? I'm seeing that wine.country is unavailable over at enom, but all I can see is "Not Registered" when doing the whois lookup. Is there perhaps a better way to tie into the eNom API to verify a domains availability, instead of relying on the inaccurate whois information? I've found this to be a problem with several of the lookups over time. I've had to NOT include certain TLD's because of this. - - - Updated - - - Also not working are the following. .BEER (see dark.beer for example) .COOKING (see spicy.cooking for example) It seems that this could be fixed if the eNom module for WHMCS would enable searching directly against the API at eNom, instead of using the whois server for verification. This just seems like such an odd way to confirm a domains availability to me.

I'm in a real pickle here. Since upgrading to version 5.3.3, has anyone gone to "Addons -> eNom New TLDs" and tried clicking "Update >>"? Can someone try this and let me know what happens? Does it work? Do you get an error message? Also, is anyone in the same boat as me, where you manually installed the "eNom New TLDs" addon module, and when you go to "Setup -> Addon Modules" you now see TWO different modules in there? One is listed as "eNom New TLDS" version 1.0, and the other is listed as "New TLDs" version 1.1. Both authored by eNom, but with different file names and paths. Per eNom's instructions, I had tried to remove the 1.0 plugin I installed and then activate the 1.1 module that is apparently built into WHMCS. After disabling and removing the original 1.0 plugin, I can no longer get either to activate without error. I get the following error. "Fatal error: Exception thrown without a stack frame in Unknown on line 0". I've tried restoring my database tables relating to the new TLD's module. While it seems to be active, when a customer goes to the new tld portal, they receive the following error message. "Oops! This portal has been disabled." I've got customers who used the portal to place pre-orders, and create watch-lists. None of the customers can get to the status of their watch-lists or pre-orders, which is going to be a real problem if any of these go to auction or require follow up. I may have customers who may lose out on their domain name without being able to access the interface. Seriously disappointed and wondering if anyone can confirm similar problems after upgrading to 5.3.3. Thanks Richard

Just a quick update. I added the whoisservers listed about by greghl, and it seems to work for .bike at least. I went ahead and placed an order as a test and it does seem to be working. While certainly I can't speak to the premium domains as a potential issue. I suppose I will log another ticket with eNom asking them about that problem.

No kidding Varial in the "Ugh" statement. I'm sooo extremely disappointed in eNom's implementation of the new TLD's. I specifically paid money for a particular .bike domain. I can see at Donuts.co that it was awarded to eNom as the sponsoring registrar, and yet eNom awarded it to someone else without any explanation as to why. No chance to pay a premium price or to bid on it or anything. I've spent a significant amount of money marketing the new TLD's, and I can't even explain the process to my customers. There seems to be no logic at all to the process. The New TLD interface is absolutely horrible. I can see that some domain names can be ordered for a different price directly at eNom.com by agreeing to pay a higher price. But this same option is not possible through the WHMCS Addon module that they've provided to the reseller community. I'm now stuck telling my customers they must go directly to eNom.com to order their domain name, or that they must use a competitor like GoDaddy. :-( I feel a bit betrayed by eNom after having spent so much on marketing the new names on their behalf. And the differing price for the premium domains basically means I'm unable to implement for my customers directly on my website. If anyone has further information one how to implement selling these new TLD's reliably, I'd sure love to hear about it. I'm entirely open to using a registrar other than eNom at this point. Maybe it's just too complex a process for any of them to get it right from a reseller API Interface perspective? Thanks greghl for posting the details for the whois file. It's at least a start.

Update : I have a test environment where I did a few tests to narrow down my options for dealing with this issue on my own as I can't seem to get support elsewhere. It seems that in the absence of cookies, eNom's new TLD addon identifies itself to the tldportal.com website somehow based on the id field in the tblclients table of the WHMCS database. So.... I'm going to... 1) create a new account for my customer. 2) move their hosting packages and domain names to the new account. 3) manually modify the invoices to point to the new account in the database. 4) search for any other references (like notes or emails or gateway transaction logs) and manually change them in the database to be associated with the new account. 5) claim the OLD customer account as an orphaned account for myself to manage my new TLD pre-orders. Not pretty, but I seem be left with little other choice.