Leaderboard

Thanks, Kai for your valuable feedback. The thing is we remained a long time loyal Hexonet partner because of the wonderful support that was provided by you and your team. You were always receptive to our ideas and feature requests, and improved the modules making them the best ones out there. It's why we knew we will never leave Hexonet despite better pricing available elsewhere. And now, here we are completely lost and abandoned at the moment. We wrote to CNIC asking us to at least give us the same terms as we had with Hexonet. But they came back saying we must pay the new account fees, apply for promos manually for each TLD and get pre approvals, and then follow up on the success of our promo campaigns to be considrerd for promos again, and pay high tiered registration and renewal pricing unless we have a high volume of domains. We did not have to do all of that with Hexonet. What's good for the goose is good for the gander. What was working with Hexonet should work with CNIC. In fact, CNIC being larger should offer even better deal and more support to its partners, but it's completely opposite. Charging account fees, imposing tiered pricing with smaller partners having to pay higher prices, and having to opt for promotions manually for each TLD, and then following up on progress are all counterproductive and serve no purpose whatsoever. These issues will force loyal partners like us to look elsewhere to support our clients. It goes without saying that both promotional and discounted pricing should be applicable across the board and be available to all partners allowing them to support their clients and remain competitive, and there shouldn't be additional account fees on top. We are very sad that we are being forced away from the modules, company and team we loved. Best, FW - RD

Yup if this is the case then its time to move, we are fortunate in that DNS.business have offered us cost price to move domains in so we encourage our clients to migrate at cost and do this in bulk. Will have to get a mail sent out tomorrow and start migrating because this is BS, and I told them (Centralnic) this was a stupid idea a few months back when they engaged with us asking us to move all of our domains over. Despite the monthly amount being marginal, $6 or what ever it was, its about principle. OpenSRS pulled similar sketchy unethical * and we moved from them to Hexonet

Update a week later: We still haven't heard back from our KAM, despite CentralNIC promising us a response within last week. CentralNIC failing to keep their promises and charging us a "service fee" means that our CEO has given us the green light to start finding another company to do business with instead of CentralNIC. The price increase for regular domain operations is not what made him make that decision. It's the fact that CentralNIC responds to important questions really slow doesn't keep us updated when they're supposed to introduces a laughable service fee (his words) that has no purpose. CentralNIC should be more than capable of generating a profit since they're not even a cheap provider. The service fee is just a way to grab more money, and I'm pretty sure they settled on $6 per month because that's a low enough amount that 90% of their resellers won't complain. So, unfortunately, we'll most likely move to another provider unless CNR suddenly steps up their game.

I'm trying to achieve a support ticket reminder setup. If a ticket within the sales department is in the status of Answered for 3 days or longer, I want to trigger another Supply Reply email reminding the client that the ticket is still needing a reply. The following script is what I have; however, it doesn't seem to be working in my tests. What is wrong with the current code? <?php use WHMCS\Database\Capsule; // Require the init.php file to access WHMCS functions require_once dirname(__FILE__) . '/../../init.php'; // Set time threshold (72 hours in seconds) $timeThreshold = 72 * 60 * 60; $currentTime = time(); // Get tickets that meet our criteria $tickets = Capsule::table('tbltickets') ->where('department', '=', 1) // Sales department ->where('status', '=', 'Answered') ->where('clientunread', '=', 1) ->get(); foreach ($tickets as $ticket) { // Get the last reply timestamp $lastReply = Capsule::table('tblticketreplies') ->where('tid', '=', $ticket->id) ->orderBy('date', 'desc') ->first(); $lastReplyTime = strtotime($lastReply ? $lastReply->date : $ticket->date); $hoursSinceReply = ($currentTime - $lastReplyTime) / 3600; // Check if it's time to send a reminder (every 72 hours) if ($hoursSinceReply >= 72 && ($hoursSinceReply % 72) < 1) { // Send reminder email $client = localAPI('GetClientsDetails', array('clientid' => $ticket->userid)); $merge_fields = array( 'ticket_id' => $ticket->tid, 'ticket_subject' => $ticket->title, 'client_name' => $client['client_name'], ); sendMessage( 'Support Ticket Reply', // Email template name $ticket->userid, // Client ID $merge_fields // Merge fields ); // Log the reminder logActivity("Sent reminder for Ticket #" . $ticket->tid . " to client #" . $ticket->userid); } }

It only works with Hexonet. It was complete a few weeks before they announced the migration to CentralNic lol. There's no point in sharing it, nor am I allowed to. We're gonna go with Dynadot. Prices seem even cheaper than Hexonet. I'm sad that we're no longer going to do business with Hexonet, but I'm fucking ecstatic about not having to join CentralNic for long. Our CentralNic KAM just cost them $30.000 (probably more, as they are more expensive than Hexonet) just by being an idiot. We got a standard "I'm so sorry about the delay, we're doing everything we can to catch up on tickets, and we appreciate your understanding and patience"-reply. That was the only thing in her reply to us - she didn't answer our questions. In her signature, it also said she doesn't work Fridays... Oh, and she was sick for 3 weeks which is why we didn't receive any reply... And nobody at CentralNic had the brain capacity to assign her clients to someone else. After we told her we had no patience and already had planned the migration to another registrar, she responded to our questions within a day, lol. Suddenly, they want to negotiate prices. Hexonet was by far the best option for WHMCS, thanks to the amazing module. Problems were solved fast. New things were added almost the same day as requesting them. Kai has pushed 4 releases of the module today - that's wild! It really sucks that CentralNic has ruined everything. I have a hunch that Team Internet is going to lose a lot of money. CentralNic's prices might be slightly more expensive (depending on TLDs and your portfolio size) but I don't think they accounted for the amount of resellers leaving them.

Addons can't be selected after a billing term change when using the twenty one cart template. This could frustrate potential buyers into not ordering, or at minimum prevent you from upselling those addons. This is a bug in the twenty one cart template javascript - they reload the addons section content dynamically and forgot to rebind the javascript to make it work again (fantastic job testing WHMCS devs!) STR: Add a product with an addon to your cart When editing the product, change the billing term Now attempt to add or remove an addon Nothing will happen because the javascript to add/remove the addon isn't working. It's possible it works if you just click the checkbox with no visual indication (but who really cares if that's true; nobody would know) I've reported this as a bug, they said "Yep, this is a bug... we'll get to it eventually, it's not really a priority. Probably only when we totally redo our cart template with WHMCS v9" was the gist of the reply, even though this means hundreds of WHMCS users currently can't upsell addons when someone changes their billing term during the checkout process. They also said they'd consider releasing a hotfix only if enough people report the issue, so maybe I'm totally crazy and nobody uses the default cart that comes standard with WHMCS AND addons at the same time. But if you do, you should definitely complain to WHMCS support because apparently that's what it takes to get a hotfix released. I could edit the javascript for them to fix it, but I'm *really* tired of doing their work for them. I have, in the past, gone so far as to submit bug fixes as pull requests on their GitHub repositories, just to have them ignore the PRs AND raise WHMCS prices. So, if they're not going to be kind enough to support their own product, why should I? This is the mentatlity WHMCS is incentivizing with these kinds of policies; I can't understand why they wouldn't rather have their community rally *around* them rather than against them, particularly alongside price increases.

@Evolve Web Hosting They said it has case ID CORE-18810 I suspect this affects a lot of customers and they just haven't noticed that it's a problem for them and has been for a while, which is why I wanted to provide this clear warning to everyone.

@websavers I think I reported this not too long ago as well. I reported it during the last beta hoping they'd fix it there but they gave me a case number which I can't find at the moment. It's actually been happening for quite some time. They told me it's because it's not updating dynamically on the screen but the calculation is done correctly.

For me, I discovered the IP range that whmcs uses for the callback, was getting blocked in cloudflare, which I use to help prevent ddos attacks. So, you have to whitelist the IP range in cloudflare, or on your server, to allow the callback requests to complete. I can't recall the IP range but it's an Amazon AWS range. If you contact whmcs support they will tell you.

The language file, it's on about lines 1226/7. Maybe this one? $_LANG['helloname'] = "Hello, %s!";

Yes, you are indeed right! I just had to read what you brought, Thank you for this!

@Web Host Pro You can change the name by using a language override file. In the /lang/ folder, create a new folder called /overrides/ and copy the language file you wish to edit (ie. english.php) and then make your language changes to that file. To get you started w/ a hook. I think ('Home') is the correct value but I did not look in developer tools to confirm. $navItem->setAttribute('target', '_blank'); is only needed if you want to open the link in a new tab / window. Otherwise, comment it out or remove it. <?php use WHMCS\View\Menu\Item as MenuItem; add_hook('ClientAreaPrimaryNavbar', 1, function (MenuItem $primaryNavbar) { $navItem = $primaryNavbar->getChild('Home'); if (is_null($navItem)) { return; } $navItem->setUri('https://www.yourdomain.com/page.html'); $navItem->setAttribute('target', '_blank'); });

We will be migrating your portfolio from Hexonet ot CentralNic Reseller, so at least by that not more work than signing up and to switch TLDs, Domains, Lookup Provider in WHMCS from HEXONET to CentralNic Reseller after the Migration (while using our CNR Registrar Module, not the one of WHMCS). -> WHMCS - Migration from HEXONET to CentralNic Reseller – Hexonet Support Center Honestly, from technical side, I can forward that this merger is a mandatory step. We maintain two Registrar Systems (HEXONET and CNR) which are highly similar. On both sides, we see a huge lack of man power, plus separate infrastructure and related costs. A merger is here for us mainly to improve such things and not for milking customers. Again, that's just my point from technical side. Mergers are a hard topic, for both sides. Please, don't get me wrong - I just want to offer a different view to that - my intension is not to proactively add arguments speaking for Team Internet. I just see this going into a wrong direction. There are other reasons behind that merger. Acquisitions and Mergers are happening everywhere in the domain industry, you can't expect it will ever stop at your registrar of trust - while I fully agree that you should find a way to continue with your loyal customers. Still, there's the pricing topic... let me also forward, that I shared the ongoings with Management and my personal frustration as well. It is not that funny to work for years proactively for customers, offering premium customer support, reacting even over the weekend on messages, pushing for your WHMCS needs and now to finally see this ending here. I mentioned exactly that also in my escalation message as well. Probably, this is one of my last comments here as I can't change things and all this is not my scope. However it continues, it was a pleasure working with you.

Yes! The pricing is extortionate. There's no way our users will pay that kind of pricing. And there's definitely no way partners can survive this debacle. Mergers & Acquisitions like that are always to monopolise and fleece the partners and end-users that helped make the platform a success. That's greedy inconsiderate capitalism for you. Hexonet, at the very least, should have negotiated better terms for its partners. What a sad state of affairs!!

Besides your own .dk module, the .za and .br modules can provide some inspiration/code snippets for your /se/.nu modules.

Dynadot has very competitive pricing - the top TLDs are cheaper than our current prices with Hexonet even 😅 The only downside is that Dynadot doesn't offer some TLDs like .se and .nu but we're considering signing a registrar agreement with Internetstiftelsen (.se and .nu registry) directly which would save us almost $7000 yearly - and we don't even have that many domains from those TLDs. There's around a 350% markup in the registration/renewal price with Hexonet and CNR compared to the registration/renewal fee with the registry itself. We've already built a module for WHMCS that can communicate with Punktum DK (the registry for .dk domains) and I don't believe modifying it to work with Internetstiftelsen would be difficult at all.

Is there a feature or setting for password policy management within WHMCS? Specifically for expiring user and admin passwords after a certain amount of time, complexity etc. I didn't see this anywhere and maybe others are using a custom module? Thanks for your feedback! Ken

interesting. Cost?

Hi @rcartists, It's in the header.tpl template file: {if $adminMasqueradingAsClient || $adminLoggedIn} <a href="{$WEB_ROOT}/logout.php?returntoadmin=1" class="btn btn-return-to-admin" data-toggle="tooltip" data-placement="bottom" title="{if $adminMasqueradingAsClient}{lang key='adminmasqueradingasclient'} {lang key='logoutandreturntoadminarea'}{else}{lang key='adminloggedin'} {lang key='returntoadminarea'}{/if}"> <i class="fas fa-redo-alt"></i> <span class="d-none d-md-inline-block">{lang key="admin.returnToAdmin"}</span> </a> {/if} Out of interest, why would you want to remove the "Return to Admin Area" link from the client area, as it's only displayed to admins when Logged in as a Client Account Owner?

FossBilling is being used by at least one really good domain and hosting provider and that too successfully. The owner is doing a heroic job maintaining it actively on Github in the interests of Open Source for everyone: billing .hostbybelle .com Blesta too is being actively used by a number of very reputable domain and hosting providers that I know and have worked with. After so many years of you know what, I have come to terms with the fact that things are not going to get better unless we want to make some compromises and sacrifices to move in a different direction. That's the way to go, for me at least, from now on.

where to start.. the security options are useless, if you enable them, they cause a lot of other issues. Tickets are always assigned to the account owner, regardless who opens them. this obviously causes problems when a clients other staff opens a ticket, as it always has the wrong name on it, and someone who doesn;t need to gets all the replies. the only way for a contact to open a ticket in their own name is via email, so you have to allow that. then as soon as you assign the ticket to the account, it changes the name on it. there is no reliable way to stop unauthorised people opening tickets without causing other issues a mentioned above. So much content gets stripped out of tickets and there is no way to view it, so there is often important content and links you cannot see, so you then have to tell client to send as an attachment instead. All this and more has been in the feature request system for 10+ years

Run this query via phpmyadmin: UPDATE tblconfiguration SET value = '' where setting = 'CaptchaSetting'; After that reconfigure the captcha.

This worked thanks!

Hello Dineo, WHMCS can surely automate payments and manage the subscription of services. It comes with a range of payment gateways to integrate with the main payment processor providers. It includes a native module for collecting payments as a direct debit (aka debit order): https://docs.whmcs.com/payments/payment-gateway-modules/direct-debit/ Our Sales team is also happy to answer any questions you have and you may reach them here: https://www.whmcs.com/contact/

Seriously WHMCS, fix this issue. There is no reason "edit my site with SiteJet" should be shown to a customer when they are not using "SiteJet", or when no options to use SiteJet have been specified in WHMCS. It's stupid and an intrusion into our customer relationships, not to mention a problem that someone could mistakenly overlay their non-sitejet site with this option displayed. Customers using WordPress are NOT going to switch to SiteJet because this is in their face!!!! All it does is cause confusion. F'n Fix it! DUMB, DUMB, DUMB, DUMB

Stealing money and not providing services. I do not recommend it! More information you can find here: https://www.trustpilot.com/review/livechatinc.com

How can your customers use SiteJet if it's disabled in the feature manager? And why is this not something we can turn off from WHMCS? It's causing so many issues for me.

I'm bewildered that this is even a question. Why would you *forcibly* add this without a option to turn it off? WHMCS is used by thousands of web development companies who want to sell their own development services and not push people to use Sitejet. Your motivations here are very transparent - it's just like the debacle with the SSL warning icons. You guys are just trying to sell your own services. It's been years since that "feature" was added and after years of requests there is still no way to turn it off. The answer is simple - stop adding features without giving clients an option to turn them off. Surely this cannot be that difficult of a concept to grasp?

Hello, A few years ago WHMCS used to have a admin homepage widget that would display the estimated income broken down by month, year etc. Does anyone know what happened to this? Why was it removed and is there a new version/replacement? Thanks

You need to beware of all this company that offer WhatsApp WHMCS module. I see WHMC S Marketplace remove all WhatsApp application, they're not allowed to add any WhatsApp module no more. Don't know the reason

Sorry its working./includes/hooks/ is the directory Many thanks, yay its back 🙂

WHMCS works wonderfully on Nginx (faster at the least), however WHMCS don't provide enough documentation. You can find all the tools you need to put things together yourself using Google, but I wanted to start this thread (and hopefully keep it updated) to keep track of the latest directives required. I'm not trying to teach you how to use Nginx or how to configure it. WHMCS will load and install just fine, but you will run into a few links that don't work in the admin and client side. At the least you need to include the following directives (including a block of the /vendor folder, which WHMCS do actually provide directions on ) : https://gist.github.com/xyzulu/dbe2762c131b7bf3fbfc67056a565ae0 .. if you don't know where to use these directives, then Nginx and WHMCS probably isn't for you. If you have any suggestions on better directives, or run into and issues please let me know here.

Hello, you can start by editing the file modelos/{your-template}/header.tpl. and add the tag <meta name="robots" content="noindex,nofollow"/> This helps index only public pages on whmcs - I personally do not recommend {if $filename=='clientarea' or $filename=='login' or $filename=='register'} <meta name="robots" content="noindex,nofollow" /> {else} <meta name="robots" content="index,follow" /> {/if} Greetings Luiz Araújo

I use the following hook to run cron jobs whenever I want on my dev systems. It automatically adds a button on top of your WHMCS (the organge one in the screenshot below). When you press it... The "Cron last run" resets so you can run it multiple times per day The "Time of Day" is autoimatically set to current hour The cron runs via curl() Keep in mind that I'm just copy/pasting my script that assumes cron.php is in ROOT/crons directory. As I said earlier, I use it on dev installations of WHMCS where I don't need to move crons directory. You surely need to change it so that it can run your cron.php file that is above "www". <?php /** * Add button to run WHMCS Daily Cron Job on click * * @package WHMCS * @author Kian */ use WHMCS\Database\Capsule; add_hook('AdminAreaHeaderOutput', 1, function($vars) { // Simulazione Cron if ($_GET['simulatecron']) { $SystemURL = Capsule::table('tblconfiguration')->where('setting', 'SystemURL')->first(['value'])->value; Capsule::table('tblconfiguration')->where('setting', 'lastDailyCronInvocationTime')->update(['value' => '']); Capsule::table('tblconfiguration')->where('setting', 'DailyCronExecutionHour')->update(['value' => date('H')]); $ch = curl_init(); curl_setopt($ch, CURLOPT_URL, $SystemURL . 'crons/cron.php'); curl_setopt($ch, CURLOPT_HEADER, 0); curl_setopt($ch, CURLOPT_RETURNTRANSFER, true); $output = curl_exec($ch); curl_close($ch); } $output = <<<HTML <style> .katademo1 { color:#fff !important; background-color:#eaae53 !important;} </style> <script type="text/javascript"> $(document).on('ready', function(){ $('body>.topbar>.pull-left').append('<a href="index.php?simulatecron=1" title="Each press simulates the Daily Cron of WHMCS" class="update-now katademo1" id="simulatingcronjob">Run Daily CronJob <i class="fa"></i></a>'); $("#simulatingcronjob").on('click', function(e){ if (confirm('Simulating the Cron Job might take a few minutes. Please be patient.')) { $(e.currentTarget).find('.fa').addClass('fa-pulse fa-spinner'); } else { e.preventDefault(); } }); }); </script> HTML; return $output; });

Here you go... This will return the left sidebar of service information when the service page is displayed <?php use WHMCS\View\Menu\Item as MenuItem; use Illuminate\Database\Capsule\Manager as Capsule; /* Add credentials to the end of all secondary sidebars. */ add_hook('ClientAreaSecondarySidebar', 1, function (MenuItem $secondarySidebar) { /* Get the credentials. */ $service = Menu::context('service'); $username = "{$service->username}"; $serverid = "{$service->server}"; $domain = "{$service->domain}"; $password = "{$service->password}"; $server = Capsule::table('tblservers')->where('id', '=', $serverid)->pluck('hostname'); $ipaddress = Capsule::table('tblservers')->where('id', '=', $serverid)->pluck('ipaddress'); $name1 = Capsule::table('tblservers')->where('id', '=', $serverid)->pluck('nameserver1'); $name2 = Capsule::table('tblservers')->where('id', '=', $serverid)->pluck('nameserver2'); $password = decrypt($password); /* If the username isn't empty let's show them! */ if ($username != '') { /* Add a panel to the end of the secondary sidebar for credentials. Declare it with the name "credentials" so we can easily retrieve it later. */ $secondarySidebar->addChild('credentials', array( 'label' => 'Service Information', 'uri' => '#', 'icon' => 'fa-desktop', )); /* Retrieve the panel we just created. */ $credentialPanel = $secondarySidebar->getChild('credentials'); $credentialPanel->moveToBack(); /* Show the username. */ $credentialPanel->addChild('username', array( 'label' => $username, 'order' => 1, 'icon' => 'fa-user', )); /* Show the password. */ $credentialPanel->addChild('password', array( 'label' => $password, 'order' => 2, 'icon' => 'fa-lock', )); /* Show the password. */ $credentialPanel->addChild('domain', array( 'label' => $domain, 'order' => 3, 'icon' => 'fa-globe', )); /*show the server IP*/ $credentialPanel->addChild('ip', array( 'label' => $ipaddress, 'order' => 4, 'icon' => 'fa-info', )); /*show the server name*/ $credentialPanel->addChild('server', array( 'label' => $server, 'order' => 5, 'icon' => 'fa-server', )); /*NS1*/ $credentialPanel->addChild('name1', array( 'label' => $name1, 'order' => 6, 'icon' => 'fa-info-circle', )); /*NS2*/ $credentialPanel->addChild('name2', array( 'label' => $name2, 'order' => 7, 'icon' => 'fa-info-circle', )); } }); At some point, long, long ago, this was in there, but taken out. This will return it.

Does this mean that its the end of Hexonet and we're now being forced to pay to have access to our domains at CentralNic? I received some random email in German which I couldnt be bothered to read and then later received an email in English explaining that it was a mistake.

Hello, To add on to our previous message, this error will typically mean that something is actively preventing the WHMCS API from reaching the server, specifically one of the following: 1. Incorrect IP address specified for the server. 2. Firewall rules blocking port 2087 for your IP (or all IPs). 3. CSF requiring the IP to be whitelisted for API access. 4. CPHulk blocking the connection for failed connection attempts. 5. Host Access Control on the server in question not having an allowance for your installation IP. Each of these can cause this error, even if your installation is located on the same server you are connecting to.

HI how does WHMCS manage domains auto-renew is it thorough cron-jobs ? some domain registars doesn't have the auto-renew feature