Jump to content

Recommended Posts

Dear WHMCS Community,

As we, up to now, did not use this community to promote us and our modules, I'll give it a try.
To introduce myself: I am the Middleware Department Lead at HEXONET GmbH in Germany. My team is responsible for third-party integrations (WHMCS, Blesta, ...) and for providing tools for custom integrations.

With HEXONET (located in Germany and Canada) you can easily resell and manage domains. We do our best to support our customers and to improve/extend in direction of specific customer requests.
We are offering all our modules for free and we have no plans to change this. We have:

  • The HEXONET registrar module that is shipped with WHMCS (get in touch with us to get updates as that version is for behind in point of features). Supporting all known WHMCS Domain Registrar Features e.g. IRTP (contact verification), TLD & Pricing Sync, Premium Domains, etc. In general we can also deal with IDN domain names, even though not officially supported by WHMCS.
  • A drop-catching Addon to get Domain Backorders introduced in WHMCS
  • A SSLCert Addon
  • A PremiumDNS Addon
  • A module for high performance availability check
  • A widget offering you a module version overview (to see if there are new versions available)
  • A widget showing your account balance at HEXONET (as we have a prepaid backend system)
  • A module helping you to import domains in case you're starting with WHMCS / transferred to us using a non-whmcs way

Find all our modules in our github company space: https://github.com/hexonet. We have big plans in Queue and as said, we do our best supporting our customers.
Patching / Extending our modules in general happens in short as of existing CI / CD automation.

If you need assistance when starting with us or if you have any related questions, just get in touch with us / let me know.


Best Regards



Share this post

Link to post
Share on other sites
On 4/29/2020 at 1:04 PM, PapaKai said:

We are offering all our modules for free and we have no plans to change this. We have:


  • A drop-catching Addon to get Domain Backorders introduced in WHMCS


Here I'm, answering to this quite-old message, just to answer a question (and give you a suggest) about your domain backorder module.

I tried it time ago (how much time? More than one year, I guess...)

I tried it, was quite satisfied but, despite this, I gave up and canceled it.


Because created in mysql a HUGE table (between 1 and 2 GB, as I remember...). And it did in the very same main db of WHMCS, and this bring to a number of issues (the main and first important: backup, done every 6 hours, required much more time to complete, and also the daily backup, done using WHMCS function for db backup, stopped working because the db was too big).

So, if in the meanwhile you have not yet fixed this issue (and, if it's so: sorry, I beg your pardon and go on testing the new version of your module...), I suggest you a fix: allow to configure the module in order to use another db, different from the main WHMCS db.  
So, using a different db, the main WHMCS db stays "clean" and there're no issues about backup.
Even more: the user can set up a different kind backup for your module, with different policy and different timing ...

Just my two cents: thank you for your time and attention.


Share this post

Link to post
Share on other sites

I imagine the pending backorder domains and related attributes are what is imported. 

Alternatively, some kind of persistent API connection would be required to yield the same level of access to the deleting domains and not many registrars are going to sign up to host that project, much less invite the public. Perhaps you could import the backorder data into separate db and setup remote connection to it from your WHMCS database?

Edited by sitedata

Share this post

Link to post
Share on other sites
6 hours ago, sitedata said:

Perhaps you could import the backorder data into separate db and setup remote connection to it from your WHMCS database?

Yes, there should be possible some kind of MySQL trick to use as a walkaround... but it's no the simplest fix, so it's not the better    😉

The safest and most stable fix would be the option to use a different, separate mysql db. 

Share this post

Link to post
Share on other sites

Hey Guys,

sorry for my late reply. No idea why - no notification reached me. Spam folder maybe?

Anyways, thanks Remitur for that IMPORTANT feedback. That's why I can just again and again point out: Report Issues and Feature Request to us (support ticket the best). We are gathering YOUR ideas and we will work on them.
Noted down. The Drop-Catching module will need a revamp anyways in 2021 I guess. UTC timezone as basic configuration requirement is probably the biggest blocker for customers.

We'll find a solution for this.



Share this post

Link to post
Share on other sites


our ISPAPI SSL Module just got a major upgrade.

  • The Addon was completely rewritten and now offers more flexibility and an improved user experience. The product import and pricing sync has been designed to match the WHMCS TLD sync functionality, so you should feel right at home.
  • The server module now supports certificate renewals, reissues and revokes.
  • The Client Area functionality was also improved, with more useful information shown to the end user and the ability to automatically generate CSR based on client data.
  • Furthermore, the module is now fully localized in English, German and Italian, with the possibility to expand to other languages via language files.

Please note that with the new version 9.x, the minimum requirements have changed to PHP 7.2 or greater and WHMCS 8.0 or greater.

More information on the module is available on the WHMCS Marketplace
The module is open source and available on GitHub

Share this post

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

Sign in to follow this  

  • Similar Content

    • By Jmac4444
      So I have done a little research and have possibly found that this error I am getting is from GoDaddy doing some changes to their API
      Does anyone have an Idea on how I could Adapt WHMCS to these changes?
      Here is the error I'm getting:

    • By Jmac4444
      Hello there, I have been connecting some domains on GoDaddy, with clients in WHMCS but when doing so I received this Error that I have never seen before.
      The client has one extra contact but that contacts information is all filled out so I'm not sure what "fields" this error is talking about. 
      Here is the error that I am seeing at the top of the screen

      Any help would be appreciated. Thanks!
    • By Nelson Neoh
      Hi Guys,
      While coding the registrar module, TLD & Pricing Sync function, the setYears method confused me.
      Can anybody show me any reference on how the array structure should be arranged?
      Recently I tried to pass the array as follow to setYears.
      Array ( [1] => 7.5 [2] => 15 [3] => 22.5 ) It ended up show in the import screen as 7.5 years as follow screen captured, with no years pricing tap also.
      Tried with the setMinYears(1) and setMaxYears(10), but no use, the imported TLD is only configured 1st year price tier.

      Best Regards,
    • By Troy
      If you use a supported registrar, WHMCS' Registrar TLD Sync can keep your domain pricing up to date without a lot of effort. However, it does NOT sync the pricing to your existing clients' domains. The Bulk Pricing Updater isn't suited to this task either, requiring many steps to update pricing for different TLDs, billing cycles and domain addons.
      I put together a SQL query that will set the recurring amount of all client domain names in tbldomains with your current domain pricing, and figured I'd share it for those whom it might benefit.
      This was written for WHMCS 8.1.3 and MariaDB 10.3. I recommend testing it on a copy of your data, and I make no warranties regarding it's suitability to your particular environment, nor claim that it is free of error. That said, it works well for me.
      Here are some suggestions for testing this on a copy of your data, assuming you have access to the server shell as root:
      1. Export a copy of the relevant tables and import into a work database:
      mysqldump <your-whmcs-db-name> tblclients tbldomains tbldomainpricing tblpricing > ~/workdb.sql mysqladmin create workdb mysql workdb < ~/workdb.sql 2. Get an idea of the current recurring amount for all your active domains (to give you something to compare against after running the sql script):
      mysql workdb MariaDB [workdb]> select sum(recurringamount) from tbldomains where status = 'Active'; +----------------------+ | sum(recurringamount) | +----------------------+ | 50029.21 | +----------------------+ 1 row in set (0.000 sec) 3. Create a file to hold the SQL that you can run against the database:
      nano ~/domain_pricing_sync.sql The SQL to put in the file:
      SET @idp = (select ssetupfee from tblpricing where type = 'domainaddons'); SET @dns = (select msetupfee from tblpricing where type = 'domainaddons'); SET @fwd = (select qsetupfee from tblpricing where type = 'domainaddons'); update tbldomains d, tbldomainpricing dp, tblpricing p, tblclients c set d.recurringamount = case d.registrationperiod when 1 then p.msetupfee + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 2 then p.qsetupfee + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 3 then p.ssetupfee + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 4 then p.asetupfee + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 5 then p.bsetupfee + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 6 then p.monthly + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 7 then p.quarterly + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 8 then p.semiannually + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) when 9 then p.annually + (d.registrationperiod * ((d.idprotection * @idp) + (d.dnsmanagement * @dns) + (d.emailforwarding * @fwd))) end where d.is_premium != 1 and dp.extension = right(d.domain, length(d.domain) - locate('.', d.domain) + 1) and p.type = 'domainrenew' and p.relid = dp.id and c.id = d.userid and p.currency = c.currency; 4. Save the file and the run it against your work database:
      mysql workdb < ~/domain_pricing_sync.sql 5. Repeat step 2 and see what your total looks like after the update.
      Once you're comfortable the SQL works for you,  you can run it against your production database manually after you update domain pricing, or even schedule it via cron if you want to automatically keep pricing in sync. There probably isn't a good reason for setting it up to run via cron, unless like me you don't like the way WHMCS allows a user to register or manually renew a domain for X number of years, and then assumes the next renewal should be for that same number of years. I personally run this SQL daily via cron, with this line added to the very top of the SQL:
      update tbldomains set registrationperiod = 1; This way if a client has registered or manually renewed for longer than a year, this will reset the domain to a 1 year registration/renewal with the current pricing for one year. It can certainly be argued that it's a bit of an overkill to run it daily just to keep a few clients' domains who occasionally renew for longer periods reset to 1 year, but I do it anyway. For me it takes a little under a minute to run this against 5,135 domain names.
      The SQL is written to handle those who use multiple currencies (I do not), and does NOT adjust the pricing for any premium domain names that are properly set (tbldomains.is_premium = 1). It does update ALL domains regardless of status. An additional where clause to only update domains with certain statuses (i.e. where status = 'Active' or where status not in ('Expired', 'Cancelled', 'Fraud', 'Transferred Away')) can easily be added to limit the amount of records updated if you wish. This does not update any open invoices, so it's conceivable a client with an open renewal invoice will still pay an outdated price and have the domain renewed.
      WHMCS doesn't store the domain extension separately in the tbldomains table, so it has to be calculated on the fly, hence "right(d.domain, length(d.domain) - locate('.', d.domain) + 1)". The assumption is that everything including and to the right of the first instance of a period in the domain name represents the extension. I can't think of a case where this would present a problem, but it's possible and something to consider before deciding to use this.
      Someone who is more motivated than I could take this concept and build an addon module with more flexibility, such as nice UI providing the ability to only update selected TLDs with selected Status values or some such. Feel free to do so if you are so inclined.
      Use at your own risk and test thoroughly before running against your production db!
    • By SD-Reg
      hello all,
      We have successfully setup WHMCS and have a few hosting accounts running well, and are now testing out domain management. We are currently configured to use eNom as the registrar, sync appears to be working, and even the pricing sync is OK. We have initiated our first domain transfer away from GoDaddy into our own WHMCS environment.
      GoDaddy side is showing "transfer pending". It's now been past the waiting period and date they gave in email communication for able to reject the transfer, so we are anticipating the transfer to now go through. In an effort to research and follow it along to see where in the process it is, our WHMCS (both as an admin and also as the user who is transferring the domain) is showing "transferred away", and eNom does not list the domain. Are there any other troubleshooting steps to check?
      I guess we were expecting eNom to possibly have a "pending incoming" or something to show what is currently in process. Then the other confusing part is that WHMCS is showing transferred away - that makes sense from the GoDaddy side (even though it's not showing completed), but as far as our WHMCS and eNom is concerned, it should be incoming, and we don't appear to have a way to investigate further.
      thanks in advance!
  • Recently Browsing   0 members

    No registered users viewing this page.

  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated