Leaderboard
Popular Content
Showing content with the highest reputation since 10/23/24 in all areas
-
That's a hook I developed and sold to Hexonet. They've probably expanded it a lot though as this was many years ago. When I asked OpenProvider about it, they said they had a similar feature for WHMCS. If not, I'll just create one from scratch again. It's really dead simple: Intercept the domain registration with the PreRegistrarRenewDomain hook point Be aware that WHMCS will send the "Domain Renewal Failed", so you might want to abort sending this email as well Use the providers API to transfer the domain instead Write logic for TLDs that aren't renewed during transfer - these would to be renewed after transfer That's basically it. It's not even 100 lines of code. I still have the code but I can't share it.3 points
-
Hey, all! Been a few weeks since my last look at this thread. My initial thought was that we would go with DynaDot, but they do not support a lot of the TLDs we already offer. We had also ruled out OpenProvider initially because we had to pay them a yearly membership subscription. However... We've spent the last month crunching numbers and comparing various providers, and OpenProvider looks to be the best alternative. Even though we have to pay a yearly fee, we are saving thousands of euros every year because we get no markup on domain prices. We have been speaking with OpenProvider for the past week and signed up yesterday, getting a nice discount for the first year. Apparently, we are not the first one to contact them regarding the CentralNic migration. If I understood correctly, they have methods to take care of the migration from Hexonet/CentralNic to OpenProvider. Another incentive for us to move to OpenProvider is the fact they we can authenticate our domain and have them send emails on our behalf (such as WDRP messages). This is something I've been requesting from Hexonet for years because we had a lot of clients that were suspicious of emails coming from @ispapi.net, claiming to be sent on behalf of us. Oh, and they respond to tickets very quickly. We don't have to wait days or weeks. Looking at you, CentralNic. Hexonet has just announced that the migration dates have been moved (May 2025 instead of Feb 2025 IIRC). This gives us plenty of time to move everything. Initially, we thought we would actually need to top up our CNR accounts with 75$ - but it looks like that's no longer the case 😁 My boss is no longer annoyed about the migration. We are gonna save a bunch of money with minimal effort - and we get better service by the looks of it.3 points
-
@stormy, I'm glad to hear the e-invoicing feature will be a real value add for you. We are working with expert solution-providers in this space, so we're confident about delivering an easy to use and compliant solution with the broadest coverage. @andp97, Yes, by the end of the year in a pre-release version of WHMCS you will have access to this new feature. This bullet point actually describes two significant features which we're very excited about: 1. A RESTful API which provides access to the product catalogue and shopping cart logic. This will provide a suite of new endpoints to get product catalogue information, add, manipulate and get information about items in the cart (including price breakdowns and totals) and much more, all without touching the cart.php file or PHP session data. This means that power users could create their own highly-bespoke frontends whilst WHMCS handles the maths in the background, before seamlessly passing visitors to the checkout page to complete payment. 2. A brand new thin client powered by the aforementioned new API capabilities, providing a thoroughly modern purchase experience based on Vue.js. I've attached a sneak peak below. The new BuyFlow is a compiled Single-page application, meaning the layout isn't manipulated through templates, but you will be able to customise the colours to match your theme through a custom.css overrides file. The shopping cart as it exists today (cart.php and order form templates) isn't going away and will still be available if you'd like to stay with the familiar experience. Stay tuned to our blog and socials over the coming weeks for more information!2 points
-
Hi WHMCS ecosystem developers! I am excited to share an early heads-up about the upcoming WHMCS 9.0 release by the end of 2025 - a major update that brings important changes to the platform’s technical requirements. As part of this release, several core dependencies will be updated, and minimum system requirements will be increased. These changes are designed to improve performance, security, and compatibility with modern PHP standards. Key Updates in WHMCS 9.0: Minimum PHP version: 8.2 Recommended PHP version: 8.3 Minimum ionCube Loader version: 13.0.2 or higher Recommended ionCube Loader version: 14.4.0 or higher Updated dependencies: A number of underlying libraries and components have been upgraded. Some notable changes include: Smarty v3.1.48 —> v4.3.4 Legacy Smarty Tags are being deprecated and will no longer function in 9.0. Smarty Template Objects (including their use in plugins) will no longer be supported. guzzlehttp v7.4 —> v7.4.5 illuminate v7.x —> v9.0 I have attached a provisional list of dependency changes to this post. Please also use this thread to provide your feedback and ask questions of the Development Team regarding these requirement and dependency changes. These changes will require action from module developers to ensure continued compatibility. We recommend reviewing your module code and preparing for updates ahead of the release. We’ll be sharing more details, including a release window, definitive changelog and developer guidance, between now and the end of 2025 to help you get ready. Thank you for being a valued part of the WHMCS ecosystem. We appreciate your continued support and look forward to working together to make WHMCS 9.0 a successful release. whmcsv90_composerlock_provisional.txt2 points
-
Hi all, In 8.13 a small improvement was made to the accounting of refunded mass-pay invoices. Prior to this the totals of mass-pay invoices were included in the overall income statistics, but now they are excluded as it's already accounted for by the original invoices.2 points
-
But you did ask them, and not by just posting here? EDIT: This is a bit old now, but a fast search on this board found:2 points
-
Hello @ThemeMetro This is a known issue, and we have published a HotFix. For more details, please review the following. Apologies for any inconvenience. Kind regards, Stephen.2 points
-
Thanks to @Mytihost, I found an elegant solution for this issue. The following hook: add_hook('ClientAreaPage', 1, function($vars) { if (!empty($vars['clientsdetails']['customfields'])) { $customfieldsAssoc = []; foreach ($vars['clientsdetails']['customfields'] as $field) { $customfieldsAssoc[$field['id']] = $field['value']; } return ['customfieldsAssoc' => $customfieldsAssoc]; } }); makes available the value of any client custom field in a template, using i.e. the form {$customfieldsAssoc.17} (where "17" is the id field in the tbl customfields)2 points
-
Hi @Jade D, I have responded to your ticket, but just wanted to follow up here so there's an answer if anybody else comes across this. The underlying issue here is that your web server was advertising a domain other than that registered for your license. This causes the license cache in your install to be invalid, and so your install needs to check in with our licensing infrastructure to validate your license. Since the details we held about your license were different to those being advertised by your web server, your install kept making a request to our licensing API. We rate limit all requests made to our licensing infrastructure to ensure stability thereof for all our customers. If your server sends too many requests, it will be temporarily blacklisted as part of this rate limit. To resolve this, make sure that your web server is only advertising the server_name that we have listed in your Valid Domains. Wait for 30 minutes or so and the rate limit will be removed, then your install will get a response back from the licensing servers that your license is valid and access will be restored. If anybody is unable to get to the bottom of this, please reach out to our support team and we can help!2 points
-
You aren't authenticated in your hooks. The hooks aren't running as you - they're running as the system. WHMCS doesn't offer a native way of logging in as an admin in a hook. If you just want to download the invoice, you can include /includes/invoicefunctions.php and run the pdfInvoice($invoiceId) function.2 points
-
I take it you weren't here when WHMCS yanked owned license update "support addons" and we all lost any updating of those convenient owned and now worthless licenses many of us bought? I had two.2 points
-
Next week we'll test our module. It works like this: You define the old and new registrar modules New registrar should be configured as the default for new domain registrations for a specific TLD When WHMCS attempts to renew a domain, it will check if the current registrar module is defined as the old registrar in the module settings and if the new registrar has been configured as the default for the TLD Use the new registrars _GetTldPricing() function to see if EPP code is required and get the transfer price for the TLD If EPP code is required, fetch it from the old registrar using their _GetEPPCode() function If transfer price is set to 0, we assume domain is not renewed - renewal will need to happen after successful transfer (this part is still WIP) Run the the new registrar's _TransferDomain() function If anything goes wrong, send an email to admins If the transfer is successful, the client receives an email with relevant information and the domain's registrar module is updated. I plan on adding support for registrars that doesn't have a _GetTldPricing() method, but this would require feeding the module with information about EPP requirement and whether domains are renewed during transfer.2 points
-
I have started work on an addon module that can hopefully work with any registrar in WHMCS. You have to define the source and destination registrar module, and the addon module takes care of the rest.2 points
-
Hello everyone. I see that here are some respected figures in the WHMCS world. I made a decision some time ago, it is difficult and complex. I will try not to use anything from WebPros. This is a difficult decision, but I see that everyone shares the same feeling, they do not care about us. Is it extremely difficult to leave cPanel? YES We are working hard to improve DA as well, and we are also working on other open source control panels. Is WHMCS very good and does it solve a lot of things? YES We do not have viable alternatives yet, but I am sure that there are many people who are dissatisfied and very soon an alternative will appear... and when it does... well... An idea... Has anyone ever thought of 'making a clone' of WHMCS? Something that WHMCS modules could be used for? Where WebPros plays, I run. I am not criticizing people, but rather how business is conducted. I understand that we all wake up in the morning to make money. I do not use any pirated tools, it is very complex to stay competitive.2 points
-
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 Hexonet2 points
-
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.2 points
-
2 points
-
WHMCS users and client accounts have separate contact information and they require separate updates to change details like the email addresses. The user management system allows a single user to access multiple client accounts. This separates authentication and authorization from services, billing, and support. To learn how to change the client account and the user account email address so they match please review this help guide: https://help.whmcs.com/m/managing/l/1681243-updating-user-and-client-account-details With this hook added to your WHMCS installation the system will now "Sync" the Client Account Email Address to match the User Account Email Address only when the change is made under the Account Details page via the client area. This hook adds a little "Note" under the Email Address field under the Hello Client! > Account Details section of the client area to inform that when this Email Address is changed, they will be logged out and they will need to log back in using the new Email Address they just set since this hook is updating both the client account and user account email addresses. Here is an example of the Account Details page Email Address field with this note: Via the Admin Area, when a client does this change and the hook was used it will make a log entry just like this: This entry indicates that the Client/User Email Sync Script hook was a success. Now both the Client Account Email Address and the User Account Email Address match for that client account. If there are multiple Users associated with the Client Account, this will only change the Email Address of the Owner of the account. <?php /* This script will update both the Client Account Profile email address and the user account email address when the change is made to the Account Details page for the email address field. Otherwise, you would have to update the email in both places and follow this article: https://help.whmcs.com/m/managing/l/1681243-updating-user-and-client-account-details Upload this file to your /includes/hooks directory of your WHMCS installation. There will be a Log entry when this script runs. @WHMCSDanny */ add_hook('ClientAreaHeadOutput', 1, function($vars) { // Only run if the on the Account Details page via the client area. // The action is going to be "details". This will make sure this message does not show anywhere else. $action = $_GET['action']; if($action == "details") { //Input the message under the Email Address field that they will be logged out after making the change. return <<<HTML <script type="text/javascript"> $(document).ready(function() { jQuery("input[name='email']").after('<span style="color:red; font-size:9pt;"><b>Note:</b> Changing your email address here will sync the email with your User Account. You will be logged out after you change the email. You must login using the new email address you just set.</span>'); }); </script> HTML; }; }); // prevent file from being loaded directly if (!defined("WHMCS")) { die("This file cannot be accessed directly."); } else { function clientowneruseremailsync_changeUserEmail(int $client_id, string $client_email){ // call the API and grab the owner user ID $command = 'GetClientsDetails'; $postData = array( 'clientid' => $client_id, 'stats' => false, ); $results = localAPI($command, $postData); if ($results['result'] == 'success') { // success! $client_owner_user_id = $results['client']['owner_user_id']; if (is_numeric($client_owner_user_id)){ // got a number, so it should be a valid owner user ID // now to perform the update to the user account to match the email set for the client account $command = 'UpdateUser'; $postData = array( 'user_id' => $client_owner_user_id, 'email' => $client_email, ); $results = localAPI($command, $postData); if ($results['result'] == 'success') { logActivity("Client/User Email Sync Script - Emails Successfully Changed and Synced. The e-mail address is set to $client_email for the Client Account and the Owners User ID: $client_owner_user_id", $client_id); } else { logActivity("Client/User Email Sync Script - Failed to change the e-mail address to $client_email for the Owners User ID: $client_owner_user_id . Results: ". $results, $client_id); } } } else { logActivity("Client/User Email Sync Script - Failed to verify that an e-mail change occurred on the clients profile. Results: ". $results, $client_id); } } add_hook('ClientEdit', 1, function($vars) { // Only run if the clients account profile email address is being changed. if ($vars['email'] != $vars['olddata']['email']){ // email is being changed. Update owning user accordingly. // get the client ID. It should be $vars['userid'] $client_id = $vars['userid']; // get the new e-mail address $client_email = $vars['email']; // call our helper function clientowneruseremailsync_changeUserEmail($client_id, $client_email); } }); } ?> Enhanced Version - Added a checkbox and tooltip In this new updated version of this hook, I added a checkbox/tooltip for the end-users to decide if they want to use this option to sync the Email Address under the Profile page too. Otherwise, nothing happens and WHMCS works as normal. The checkbox needs to be checked before it will run the same hook code to update both email addresses in both locations. (Account Details and Profile sections via the client area) <?php /* This hook script will update both the Client Account Profile email address and the User Account email address When the change is made to the Account Details page for the email address field only. It does not work for the Profile page. This version adds a new checkbox with a tooltip to let the end-user decide if they want to use this option or not. The checkbox needs to be checked for the hook to execute. If the checkbox does not get checked WHMCS works as expected and updates just the Account email. The Profile email account will still need to be updated if they want it to be the same. Otherwise, you would have to update the email in both places and follow this article: https://help.whmcs.com/m/managing/l/1681243-updating-user-and-client-account-details Upload this file to your /includes/hooks directory of your WHMCS installation. There will be a Log entry in the admin area when this script executes. @WHMCSDanny */ add_hook('ClientAreaHeadOutput', 1, function($vars) { // Only run if the on the Account Details page via the client area. // The page action is "details". This will make sure this message does not show anywhere else. $action = $_GET['action']; if($action == "details") { //Input the checkbox and tooltip under the Email Address field return <<<HTML <script type="text/javascript"> $(document).ready(function() { jQuery("input[name='email']").after('<input type="checkbox" name="syncEmails" id="syncEmails"> <span style="color:red; font-size:9pt;"><b>Sync Email with your User Account Email</b></span><span class="form-group"> <i class="far fa-question-circle" data-toggle="tooltip" data-placement="top" title="This option will sync your Email Address Here with your Profile Email Address. You will be logged out and will need to login with your new email address. If you do not check this option you will need to update it under the Your Profile page as well"></i></span>'); }); </script> HTML; }; }); // Prevent file from being loaded directly if (!defined("WHMCS")) { die("This file cannot be accessed directly."); } else { if (isset($_POST['syncEmails'])) { // Checkbox is checked // Perform actions and the logic to check the emails and replace them with the new one function clientowneruseremailsync_changeUserEmail(int $client_id, string $client_email){ // call the API and grab the owner user ID $command = 'GetClientsDetails'; $postData = array( 'clientid' => $client_id, 'stats' => false, ); $results = localAPI($command, $postData); if ($results['result'] == 'success') { // Success we have the owners user ID from the database! $client_owner_user_id = $results['client']['owner_user_id']; if (is_numeric($client_owner_user_id)){ // We have the ID number, so it should be a valid owner user ID // Perform the update to the user account to match the email set for the client account $command = 'UpdateUser'; $postData = array( 'user_id' => $client_owner_user_id, 'email' => $client_email, ); $results = localAPI($command, $postData); if ($results['result'] == 'success') { logActivity("Client/User Email Sync Script - Emails Successfully Changed and Synced. The e-mail address is set to $client_email for the Client Account and the Owners User ID: $client_owner_user_id", $client_id); } else { logActivity("Client/User Email Sync Script - Failed to change the e-mail address to $client_email for the Owners User ID: $client_owner_user_id . Results: ". $results, $client_id); } } } else { logActivity("Client/User Email Sync Script - Failed to verify that an e-mail change occurred on the clients profile. Results: ". $results, $client_id); } } add_hook('ClientEdit', 1, function($vars) { // Only run if the clients account detaoils email address field is being changed. if ($vars['email'] != $vars['olddata']['email']){ // Wmail is being changed. // Get the client ID. It should be $vars['userid'] $client_id = $vars['userid']; // Get the new e-mail address $client_email = $vars['email']; // Call the helper function to make the change clientowneruseremailsync_changeUserEmail($client_id, $client_email); } }); } } ?> At the time of writing this post, this process was tested on the latest stable release of WHMCS 8.9.0 I hope you find this useful. If you have any feedback or questions, please feel free to reply to this thread! WHMCSDanny2 points
-
Hello, Not at all and it's highly recommended, to change the admin path.2 points
-
I am happy to say that the development cycle of vBLink 2.0 is now complete. The release was delayed for a complete ground-up rewrite after WHMCS 4 was announced. It is not ready for download just yet; I have not taken the time to create an installer or documentation because of two major issues that may become a factor in the long term success of vBLink. The first issue is vBulletin 4 support is not included. This is in part because of the fact that I do not agree with decision by vBulletin to change the licensing structure essentially us to purchase new licenses. I own three licenses, two for production sites, one for a development site. The cost to upgrade is going to be huge, especially if I choose the publishing suite. So at this point I have no access to vB4 code. The second issue is that from a business standpoint vBLink has not been a success, or at least the free/paid model that it has been distributed with. In the past year there have been over 400 downloads of vBLink but less than 2% were paid licenses making vB4 support hardly justifiable. So the question now is what to do next, and that is the reason that I am posting this message. Obviously, vBLink without vB4 support is only going to be useful for a short time until v4 goes gold. But without a solid community and financial backing behind it, I have no reason to continue development. But one promise I will make is that if I do walk away from vBLink, I will release all source code into the public domain; I do not believe in holding code hostage. If I do in fact release vBLink 2.0, I'm thinking of a 3-tier release structure... vBLink Basic (Free, Fully Encoded with only account bridging and no extras) vBLink Pro (Mid-range cost, a few admin module source files encoded, fully functional) vBLink Pro Dev (Highest cost, fully functional with full source) All feedback is welcome and will help determine the future of this vBulletin integration.2 points
-
Thanks for opening a new thread, I had posted in the 2025 one. In my case, they will be extracting an extra $25/mo in exchange for absolutely nothing. The email is hilariou,s though: "We understand any change in pricing directly affects your business, which we do not take lightly." HOWEVER, if they succeed in doing the European E-invoicing right, which I highly doubt, then the price increase would be worth it. The problem is - can we trust WHMCS with something that can get you us legal and financial trouble?1 point
-
Your idea is technically doable in WHMCS, but there are some important fiscal and accounting issues to be aware of. The main challenge is that the money would come from someone who is not your client, while the credit is assigned to a third party (your actual client). This creates a mismatch between the payment and the service, meaning you would legally need to issue a receipt or invoice to the donor even though the benefit goes to someone else. On top of that, VAT and taxes can get tricky. If the donation is treated as payment for a service, VAT normally applies, but calling it a "pure donation" isn't straightforward, since the money is effectively being used to pay for another person's services. And when your client eventually uses the credit to pay for their server, that counts as a separate transaction requiring its own invoice, which could create accounting confusion or even potential tax issues (double taxation) if not handled carefully. So, while WHMCS can handle the technical side, the real challenge is making sure this setup is compliant from a fiscal perspective. That being said, personally I would avoid playing with real money. Instead I'd create an alternative currency (credits, tokens or coins) that donors purchase and for which you issue an invoice. The beneficiary who receives the donation can then use those tokens at payment time to reduce the total of an invoice, for example by redeeming a discount coupon that adds a negative line on the invoice. That way you avoid the mismatch of receiving money from one party and assigning credit to another, and you eliminate the risk of double invoicing or double VAT payments.1 point
-
Modules Stack has introduced the advanced product page module for WHMCS platform. This module is very useful to improve the layout of product pages by updating Logo, High-quality images, Product details, Product descriptions, CTA buttons and many more. Check more details here - https://members.modulesstack.com/index.php?m=product_page&pid=5&name=product-page-module-for-whmcs1 point
-
There are few issues in the hook logic for applying credit and cancelling invoices: Incorrect array index usage in the loop You had: foreach ($invoiceData['invoices']['invoice'][0] as $invoice) This loops only over the first invoice. Use: foreach ($invoiceData['invoices']['invoice'] as $invoice) Incorrect object access You used: $invoiceId = $invoice->'id'; $creditamt = $invoice->'credit'; But $invoice is an associative array, not an object. Use: $invoiceId = $invoice['id']; $creditamt = $invoice['credit']; Incorrect variable name You had: if ($canceInvoice['result'] == 'success') Correct to: if ($cancelInvoice['result'] == 'success') Syntax error in else You had: else } Correct to: else {1 point
-
@WHMCS John Thank you for your response. "valid syntax" was the key point on this, as it was not clear on documentation.1 point
-
Hi @ZeroMB, Thanks for that information. I've logged case #WHMCS-22693 with our developers in order to have this reviewed for future releases. Whilst I cannot provide an estimated time for completion for this, once we resolve cases and push features they are available at our change log, here: https://changelog.whmcs.com/ Thanks again for taking the time to report your findings.1 point
-
1 point
-
Hi there Negar. WHMCS software will allow the following billing cycles: One Time/Monthly Quarterly Semi-Annually Biennially Triennially Daily billing is not a part of our product, and there are not currently any plans to add this. If you should decide to get started, we recommend that you review our System Requirements - http://docs.whmcs.com/System_Requirements and then you may purchase a license here: whmcs.com/orderhttps://www.whmcs.com/signup Thank you for your interest in WHMCS! Customer Service Team1 point
-
We understand your frustration, and we’re sorry to hear about your experience. To clarify, the lifetime license you purchased grants you indefinite use of the theme, but as stated on our product page, ongoing updates and support require an active subscription. This is a common practice in the industry, as maintaining compatibility with WHMCS updates involves continuous development work, which incurs costs for us as well. We’d be happy to assist you further if you choose to renew your support & Updates plan. Alternatively, you’re welcome to continue using the existing version of the theme without updates. If you have any questions about your options, feel free to reach out. Thank you for your understanding.1 point
-
I'd recommend making a backup of any files you are planning to delete. Better yet, try moving the folder outside of WHMCS document root path. I would keep the files at minimum until you've either confirmed this solution has solved your issue or not. This way you can quickly restore your WHMCS back to its previous state in case of any unforeseen errors.1 point
-
Another day another ignored WHMCS bug as this thread surpasses 60k views. Today I had a client create an order, pay via PayPal. No client account created, no order created in WHMCS. No payment received to PayPal. Client sees the transaction in PayPal which disappears within a couple of hours. Very bad look as a user of WHMCS who has seen constant price rises for software that supposedly is all about automation and ease of use. This is 100% a WHMCS bug as I've seen the exact same with Stripe. Other times the client account is created, the order created but the payment is "uncaptured" No point submitting a ticket as WHMCS refuse to accept this is an issue with their software. I now use almost stock WHMCS. Just Fraud Record in terms of modules and I have a very simple child theme of twenty one.1 point
-
No I think this is something other issue Can you check client create logs if possible post here1 point
-
@elonmusk Check log with which API user it's getting created So you can edit the role assign to that user and remove API access Hope this will help you1 point
-
You can post at https://whmcs.community/community/137-service-offers-requests/ and one of the developers can do this work for you.1 point
-
Look for something common, like a .ru domain, and block that at the TLD level (unless you have customers using those). Trying to block all spammers by individual email addresses is a game you won't ever win. More effectively, you can disallow tickets by non logged-in users. Public facing things like this are abused all the time, and recaptcha only helps a little.1 point
-
I thank you for your nice comments. I uploaded it to GitHub so that anyone who wants to take it and develop and continue.1 point
-
Sure, Thanks for the update. As you have added language option here, so it will be easy for all users to use it. Thanks1 point
-
Thanks for sharing the valuable info. It was required to disable the on cPanel / Plesk servers.1 point
-
Hello, Your website is looking nice. I just want to suggest, do minor changes in the services section to represent in a better way. Thanks1 point
-
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.1 point
-
All they do is add what they want not what their users want. Most of us are still waiting for actual feature requests to be added and old bugs to be fixed, which they just ignore. Some of those popular feature requests have been there 10+ years.1 point
-
Dear Open-Xchange customer We'd like to inform you that an OX Cloud service degradation was detected on 19/09/2024. The teams at OX had seen an issue with LDAP and items like additions, deletions and slow password changes. As of yesterday @ 12:50 BST all is working fine again and no error should come up (is any in the past).1 point
-
Stealing money and not providing services. I do not recommend it! More information you can find here: https://www.trustpilot.com/review/livechatinc.com1 point
-
This looks like what we need to stop spamming orders. Is there a plan to include this in WHMCS itself witho it being just a hook? thank you1 point
-
See here: https://github.com/hybula 😃1 point
-
Running WHMCS 8.10. Firefox just updated last night. Now when I navigate to Utilities --> WHM Connect --> click on one of my cPanel servers, Firefox delivers the message: Firefox Can’t Open This Page To protect your security, cpanel6.qwikhost.com will not allow Firefox to display the page if another site has embedded it. To see this page, you need to open it in a new window. If I click Learn More I'm directed to this article -- https://support.mozilla.org/en-US/kb/xframe-neterror-page Something is going to need to be done with WHMCS Connect to allow us to access servers with one-click like we used to be able to. I get that this was a recent Firefox change, but it'll likely end up being a change in other browsers down the road I would guess.1 point
-
@sajibdesigns You need to select a Registrar from the dropdown before clicking accept order1 point
-
For many businesses, there will be keywords that you do not want customers to be able to use. For example, you might want to prevent them from being able to create services under any of your domain names, or prevent the use of strings like "admin" or "root" in the "First Name" and "Last Name" fields. By making use of action hooks, it is totally possible to add this functionality. In this post, I'll show you how to get this setup, and how you can add your own rules. Overview To make this work, we're going to be making use of Action Hooks - specifically, the ShoppingCartValidateCheckout hook. If you've never used hooks before, I'd recommend reading our Getting Started guide, which will help you to understand the basics of what we'll be doing here. Step 1: Set up your hook file To begin, open your WHMCS instance's filesystem, and navigate to /path/to/whmcs/includes/hooks and create a new file keyword_filter.php. Now open the file, and paste in the following: <?php add_hook('ShoppingCartValidateCheckout', 1, function($vars) { // Content goes here }); This will tell WHMCS that we are using the ShoppingCartValidateCheckout hook, and will allow us to retrieve the variables provided to us. As this article goes on, we'll be adding to this base layer until we have our finished, fully-functional script. Step 2: Define your keyword filters There are many different ways that we could define what strings are banned in which fields. For maximum legibility and modularity, I've decided to use a map. This will allow us to associate one set of data (the "key"), in this case the field name(s) to apply the filter to, and another (the "value"), which in our case is a list of banned keywords. Here's the code: <?php add_hook('ShoppingCartValidateCheckout', 1, function($vars) { $fieldKeywordMap = [ [ // The 'firstname' and 'lastname' fields cannot contain the strings // "admin", "root" or "superuser". 'fields' => ["firstname", "lastname"], 'keywords' => ["admin", "root", "superuser"] ], [ // The 'email' field cannot contain the strings "@whmcs.com" or // "@google.com". 'fields' => ["email"], 'keywords' => ["@whmcs.com", "@google.com"] ], // Add more mappings as needed ]; }); Each set of 'fields' and 'keywords' is a mapping. You can add as many of these as you need. We'll be returning an error based on whether or not the field contains these keywords (i.e. if they are substrings). For example, if the user enters "admin123" for their firstname and "john.smith@google.com" for their e-mail, both of these filters will apply because the substrings "admin" and "@google.com" are present within the 'firstname' and 'email' fields respectively. You can find a full list of available fields in the documentation for this hook. Step 3: Implement logic to check field submissions for any banned substrings Now that we've defined our 'filters', we need to implement the logic that's going to make them work. Here's the full script, explained in the provided comments: <?php add_hook('ShoppingCartValidateCheckout', 1, function($vars) { $fieldKeywordMap = [ [ // The 'firstname' and 'lastname' fields cannot contain the strings // "admin", "root" or "superuser". 'fields' => ["firstname", "lastname"], 'keywords' => ["admin", "root", "superuser"] ], [ // The 'email' field cannot contain the strings "@whmcs.com" or // "@google.com". 'fields' => ["email"], 'keywords' => ["@whmcs.com", "@google.com"] ], // Add more mappings as needed. ]; // Initialise array to store error messages. $errors = []; // Iterate through all of your mappings. foreach ($fieldKeywordMap as $mapping) { // Get the 'fields' and 'keywords' separately for each mapping. $fields = $mapping['fields']; $keywords = $mapping['keywords']; foreach ($fields as $fieldName) { // Retrieve the value for the field from $vars[] provided by the hook. $fieldValue = $vars[$fieldName] ?? ''; // Check if the field is empty - if it is, skip the checks. if (!$fieldValue) continue; // Check if any of the keywords are a substring of the field value. foreach ($keywords as $keyword) { if (stripos($fieldValue, $keyword) !== false) ) { // If there is a match, add it to the list $errors[] = "'$fieldName' cannot contain '$keyword'. Please remove this and try again."; } } } } // If any errors are present, return them - otherwise, return true. return $errors ?: true; }); Here's a little summary of how it works: Iterate through all of your mappings ('filters') Check all fields for each filter If the field value is blank, skip all checks for that field - we need to do this since this field is only included for new users If the field value is not blank, carry on to checks Check if any keywords are a substring of the field value If they are, add that infraction to an array of errors to be returned If not, do nothing If there are any errors, return them. If all checks are passed and no keywords are present, return true. The only part of this code that you should need to modify is the top section, where you define your filters. If any of the filters are matched, here's what'll be displayed in WHMCS: Step 4: Prettify error messages (optional, but recommended) As it stands, our hook is completely functional. If any banned words are present, an error will be returned. However, our script looks like a customisation, and you'll probably want to make it appear like native functionality. The issues are: We're currently using the $fieldName, which doesn't read like English Language used doesn't fit in with the rest of WHMCS's error messages To second issue is fixed by adjusting the error message, so that's easy! To fix the first problem, we'll use another map to correlate each $fieldName with its "English equivalent" (which I've just called $friendlyFieldName: <?php add_hook('ShoppingCartValidateCheckout', 1, function($vars) { $fieldKeywordMap = [ [ // The 'firstname' and 'lastname' fields cannot contain the strings // "admin", "root" or "superuser". 'fields' => ["firstname", "lastname"], 'keywords' => ["admin", "root", "superuser"] ], [ // The 'email' field cannot contain the strings "@whmcs.com" or // "@google.com". 'fields' => ["email"], 'keywords' => ["@whmcs.com", "@google.com"] ], // Add more mappings as needed. ]; // Map field names that you're using above to their "English equivalent". $friendlyFieldNames = [ 'firstname' => 'First Name', 'lastname' => 'Last Name', 'email' => 'Email Address', // Add more field name translations as needed. ]; // Initialise array to store error messages. $errors = []; // Iterate through all of your mappings. foreach ($fieldKeywordMap as $mapping) { // Get the 'fields' and 'keywords' separately for each mapping. $fields = $mapping['fields']; $keywords = $mapping['keywords']; foreach ($fields as $fieldName) { // Retrieve the value for the field from $vars[] provided by the hook. $fieldValue = $vars[$fieldName] ?? ''; // Check if the field is empty - if it is, skip the checks. if (!$fieldValue) continue; // Check if any of the keywords are a substring of the field value. foreach ($keywords as $keyword) { if (stripos($fieldValue, $keyword) !== false) { // Translate the field name to a nicer name for the error message. $friendlyFieldName = $friendlyFieldName[$fieldName] ?? $fieldName; // Add it to the list $errors[] = "$friendlyFieldName cannot contain '$keyword'"; } } } } // If any errors are present, return them - otherwise, return true. return $errors ?: true; }); Simply add a new mapping for each $fieldName that you use in the $friendlyFieldNames array, and they'll read well and feel like a native part of WHMCS: And there we have it: a hook script that can be easily extended to include as many fields and keywords as you require, and it feels totally native too! Customising/extending this script Feel free to customise this script to you heart's content, whether you want to change how it behaves or extend its functionality. However, please keep in mind that our Technical Support team won't be able to help you troubleshoot any problems that you may encounter should you make any changes. Use at your own risk. Suggestions for other "Tips & Tricks' articles If you'd like to see an example of how we can customise WHMCS in other ways, please do give us your suggestions!1 point
-
the quick way, before they've registered, would be to ensure that those client fields aren't optional during registration and/or ordering... https://docs.whmcs.com/Other_Tab#Optional_Client_Profile_Fields but if they've registered before you've made those changes to settings, then the next step depends on how thorough you want to be... you can certainly, once they log in, redirect them to to the contact details page and force them to complete the required fields before they can do anything else... hooks to do that, or similar, have been previously posted.1 point