Leaderboard

Yes, I agree they should be an option

This new "feature" is terrible and is a fundamental change. This feature does not conform to most businesses and should be an option if there are other regulatory purposes in other countries. It severely limits the flexibility of the system and limits its function. I highly recommend a switch to disable this new "feature".

While I understand that bugs are part of any Release Candidate cycle, it's concerning that we are still discussing basic optimization issues like proper OPcache support. And let's not even get started on the fact that we still don't have 100% native Nginx support. This becomes particularly ironic with the introduction of the new WHMCS Cloud Solution. With cloud hosting, the resource costs are on their side, so you'd think they'd be rushing to support Nginx to reduce their own infrastructure expenses. It's like being sold a high-performance engine but being told you have to power it with hamster wheels. Maybe once their bills start rolling in, Nginx support will suddenly become a priority. This all points to the bigger issue: the development velocity. Core development feels like it's just about "keeping the lights on" (PHP/ionCube updates) rather than actual innovation. This stagnation has allowed third-party developers like ModulesGarden to build entire businesses by selling us functionality that should have been in the core a decade ago. When you look at the "Total Cost of Ownership" license fees + necessary third-party modules, the value proposition is slipping. Newer platforms like Upmind are entering the market with an API-first architecture and modern features built-in from day one. If WHMCS continues to outsource innovation to the community while raising prices for maintenance updates, that competitive threat is going to become an exodus very quickly. We need core features that match the modern hosting landscape, not just compatibility patches.

A system should be designed to be functional for its paying customers, rather than being dictated by external regulations that may or may not be applicable to all users. Implementing such a feature without a proper disable option is impractical and appears to be an oversight. The current suggested workarounds are ineffective for the majority of standard web design and hosting businesses. Remember, most projects start off with two 50% (published) invoices (deposit and final) from the quote when converted and the final invoice typically gets tweaked for various reasons. This change would prevent that quick 10 second update to it. WHMCS should focus on developing efficient software that delivers value to its users, allowing us to manage legal compliance independently, rather than introducing features that hinder usability.

This is what one WHMCS Staff tell me You have the option to make the change to your WHMCS configuration.php file and add the line $allow_adminarea_invoice_mutation = true;, but it is your decision whether to do so. When this line is present in your configuration.php file, the system will permit most of the changes to invoices that existed before WHMCS version 9.0, notably: Line items can be changed for invoices in any status (when in the "Manage" mode and with the correct admin user permissions set). All attributes are available in the Options tab regardless of the invoice status (when in the "Manage" mode and with the correct admin user permissions set). Payments can be applied in the Add Payment tab regardless of the invoice status (with correct admin user permissions set). Please note that using this configuration line ($allow_adminarea_invoice_mutation = true;) in your WHMCS configuration.php The file is highly discouraged, as it may permit changes that are not compliant with regional/country business regulations and complicate accounting. To bring awareness of this, a Warning health check will appear in the System Health Check summary when the value is present in your WHMCS configuration.php file. Additionally, all “full administrators” will see an Admin Warning banner (which can be dismissed up to every fortnight). You may want to add it temporarily if you do need to make the changes listed above, which were changed in WHMCS version 9.0 to improve invoice management and ensure tax compliance by keeping invoice records consistent. If you do not see any warnings or have issues with editing invoices or changing their status when this line is added, please let us know. Starting with WHMCS version 9.0, non-Draft invoices are immutable. This means you cannot edit transactions (now listed under the Ledger section on the invoice), add or remove items, or modify descriptions on an invoice once it’s no longer in the "Draft" status. This change is intended to improve invoice management and ensure tax compliance by keeping invoice records consistent. For more information on invoice management in WHMCS version 9.0, please refer to the following documentation: https://docs.whmcs.com/9-0/billing-and-invoicing/invoice-management/

I never imagined that a simple update could introduce so many problems — and even worse, apparently without proper testing. It is absolutely ridiculous for a financial management system to have its own financial logic broken. In the last 24 hours, I finally received a response on the open support ticket, along with a so-called “patch” (attached). In practice, this patch only fixes the reports by hiding the incorrect ledger entries. However, in several other areas of the system, the incorrect postings are still happening. For example, the “Transactions” tab inside the client profile continues to show wrong values and misleading entries. So, in short, this patch does not actually fix the root problem — it only masks it in specific reports. For now, apply it if you want to slightly reduce the visible impact, but be aware that the financial logic is still broken in multiple parts of the system. At this point, we are seriously considering rolling back to a previous version — or even migrating away from WHMCS entirely. Year after year, the pricing increases exponentially, while the quality of support continues to decline and critical issues like this keep happening. The current level of instability and support simply does not justify the price they are charging anymore. whmcs_v9.0.0-supporthotfix.1_750a0b77ff.321_WHMCS-24949.zip

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.txt

Okay, maybe I was too quick about credit notes. It seems a lot of the features are "coming soon™️". This is not a Release Candidate lol. This is not even alpha. This is internal development. Nothing can convince me that this release didn't just happen because WHMCS promised us a release in December.

The one question I have is "why"? Clearly there's a need and demand for it, why is it not even considered being made optional, with warnings about not doing it or what have you. Why is it simply removed, with no options and so on.

Are there still issues after the 9.0.3 release?

add this line to your configuration.php it will go back to normal behavior $allow_adminarea_invoice_mutation = true;

Yeah this is a nightmare

I think you guys may be dramatically underestimating what AI is capable of, but I suppose we shall see. As for the post being suitable or not, Webpros has done everything in their power to alienate their client base - this type of post is the inevitable consequence of that.

"Luck" isn't really a component here. If you haven't played around with agentic coding I can see why this would seem like a stretch for you, but it's quite trivial to get a fairly simple billing system up and running quite rapidly. And like I said this is with current-level tools, in a year or two, replicating the entirety of WHMCS would likely be very doable.

Yeah, except for adding AI to domain search, this release doesn't really provide on any of the other promises. Credit notes doesn't work either. When you cancel an invoice, WHMCS just adds a transaction to the invoice. If the invoice has a total of $100, WHMCS just adds a transaction of $100 and cancels the invoice. There's no credit note or anything.

How WHMCS have set this as a RC instead of a Beta is insane. It's a huge upgrade in terms of it's impact on themes/modules. No beta, no reply from WHMCS, no forums specific to v9.

Your process sounds good apart from WHMCS. I would never recommend trying to import tables to new files. You need to update your existing install as normal. You can update from your version but you may have more luck doing a manual update. Backup everything, upload the new v8.13 files, adjust your hosting/server settings to meet the requirements (e.g you may need to update PHP) then run the installation script.

@BENELUX, Today's the day!! https://blog.whmcs.com/133775/whmcs-90-release-candidate-out-now

This week or next! It sure would be nice to double the size of the engineering team temporarily for one release every few years!

@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!

Hi @venkat.j, The current latest version is 8.13. This behaviour suggests the dates were set to 00/00/0000, either by an admin (in which case there should be an entry in the client's Log tab) or by a rogue after-market module (in which case there probably wouldn't). You can edit the date fields to set the actual dates and click Save Changes. The correct dates will be stored.

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.

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:

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.

Hello, Not at all and it's highly recommended, to change the admin path.

Request WHMCS to make it a confugurable option instead of removing it?

We always upgrade a year later for good reason. 😉 Anyways we will probably stop with WHMCS in general and we are in the process of coding our own perfect suited solution instead. Much better. Only the things you really need, no errors, easy code and much faster as well. But. It will take time. In the meantime we will still be using WHMCS.

That likely means it's setting it into an iframe, and not copying. To test, have a read here. I'd try the javascript version first (don't forget <script tags>) and see if it still loads. Link didn't paste: https://medium.com/@kesen.somar.99/securing-your-website-how-to-disable-iframes-to-prevent-click-hijacking-attacks-98cd2004720f

Stepping back from this specific issue, it does feel like a broader pattern within WHMCS rather than an isolated problem with NexusCart. I do not have insight into WHMCS internal development processes, and this is not intended as criticism of individual contributors, but from a customer and integrator perspective the overall direction can be difficult to follow. Over recent releases, we have seen recurring regressions, incomplete fixes, and features that appear to ship without being fully validated across real world installations. When combined with limited transparency around known issues or roadmaps, it creates the impression of fragmented development and weak internal communication. WHMCS is a mission critical platform for many businesses, so stability, predictable releases, and timely fixes are just as important as new features. At times it feels like significant bugs or long requested improvements are either delayed for extended periods or quietly deprioritized, which makes long term planning and confidence in upgrades challenging.

Growing a business with limited resources is tough, but the right marketing tools can make it much easier. They help you save time, avoid doing the same tasks over and over, and keep everything in one place so you're not constantly jumping between different apps. Think about all the things that go into marketing: setting up a website, posting on social media, sending emails to customers, and keeping track of projects. Doing all of that manually takes a lot of time. But with the right tools,...View the full blog post

Hi @kon, I'm pleased to hear you like the direction we're going with Nexus cart! We're going to continue with this work in 9.1 and bring this same design language to the rest of the purchase flow. The RDAP implementation has been rescheduled to v9.2. This is because we have prioritised security and financial compliance features in releasing 9.0 and will continue this focus in the subsequent 9.1 (eg. credit notes, e-invoicing, improved VAT compliance).

Also using custom.css for the theme's variables defeats the purpose of custom.css, it's now going to be replaced for every update. v9 screams minimal effort, rushed with no regard for users. If they don't care why should we?

Problem: I have a fairly old WHMCS installation (WHMCS 7.10.2 and PHP 7.3.3), which is now at the end of its useful life. The current WHMCS installation is used for both the website (service presentation pages, price lists, “about us,” etc.) and the customer area. (It seemed like a good idea at the time, but it’s not: it’s a mess, management is rigid, there’s no SEO optimisation, creating multilingual pages is a mess…) So I was thinking of installing the new WHMCS in a different directory (e.g., my.example.com) and developing the main site with WP on example.com. This way I could: leave the old WHMCS site running on example.com for as long as necessary develop the new customer area on my.example.com develop the new site offline Once everything is ready, I “just” need to: delete the site on example.com install the new WP site on example.com migrate the database from the old WHMCS installation to the new one set up a series of redirects in .htaccess from the old URLs to the new ones My questions are: Did I miss something along the way? Is there something I haven’t thought of? I'll need to migrate the database from a WHMCS 7.3.3 installation to 8.13… which tables do I need to migrate? Can I do it from phpmyadmin, or are there differences in the database structure?

Nexus is gonna disappoint you. It's just a reskinned Twenty One template (for the system template) and a reskinned Standard Cart template (for the cart template). It's only during checkout that it's different.

Key Features List Our WhatsApp Gateway: Authentication and User Management: Login, registration, and logout using CodeIgniter Shield. User group system (admin & user). User profile management. User Dashboard: Subscription overview (active plan, remaining days, message/device limits). Usage statistics (messages sent, devices connected). Alerts for expired subscriptions or reached limits. API token management for external access. WhatsApp Integration: Multi-session device management (multiple WhatsApp accounts per user). Sending of text and media messages (images, etc.). QR code scanning to connect WhatsApp devices. Message logging (delivery status, WhatsApp message ID). Message limit checks based on subscription plans. Subscription and Plan System: Various plans with device and message limits. Usage tracking (messages sent, active devices). Subscription management (active, expired). Plan upgrade/downgrade. Admin Panel: User management (create, edit, delete users). Assign groups and plans to users. RESTful API: Endpoints for sending WhatsApp messages via token. Integration with Node.js backend for WhatsApp operations. Modules: Invoices, Orders, Payments. Multi-language support (English, Indonesian, Spanish, UAE/Arabic, Chinese). Node.js Backend (whatsapp-web.js): Node.js server for running WhatsApp clients. Multi-session support with LocalAuth. Handling of QR codes, connections, and message/media sending. Logging and error handling. Security and Logging: Input validation and CSRF protection. Message and user activity logging. Environment variables for sensitive configuration (NODE_URL, etc.).

Please don't. We cannot afford yet another price increase.

Hello, It’s clear that there is an issue with your database configuration. First, try connecting to the MySQL database using the credentials provided in your configuration.php file and check whether the connection is successful.

@EnricoloDi niente! Occhi puntati su quando verra' rilasciato WHMCS 9.0 😀

Yes, this sounds correct.

This is caused by misconfigured WHOIS servers. You need to ensure the correct string for "available". When dealing with this error, you can navigate to the WHOIS interface in WHMCS admin and check some WHOIS responses for domain that status is known For example, you can use "thisdomainisn0tregistered.org" as a test for getting the appropriate response of WHOIS for a domain that is available for registration. Then, you need to incorporate your findings in the whois.json file. Configuring the appropriate values in this manner will ensure that your clients are given the opportunity to register the domain which is "available" and configured for sale in your WHMCS. Example { "extensions": ".org", "uri": "socket://whois.publicinterestregistry.net", "available": "Domain not found." }

Hey@bluesteam, I have just attempted to replicate this scenario in my test environment, but have been unable to get the same result. I would recommend opening a support ticket, and someone can take a deep dive to see if we can get to the bottom of it with you. Regards Jimmy

@bear is right in this case. AI is generally only a help if you already know what you're doing. @MytihostYou can't solve the issue using Javascript. Javascript is a client side language, so you can only use it to manipulate the data you already have received from the client. If you only want to get a set amount of records for each page, you could use the limit() and offset() methods on your collection. Unfortunately, WHMCS doesn't support the paginate() method provided by Laravel. If you're retrieving thousands of records from the database, it's going to be slower than retrieving 50.

Hello, Here, I am sharing some steps that you need to follow to fix the issue - 1. Verify the File: Check if the captcha.tpl file is present in the templates/default/includes/ directory of your WHMCS installation using FTP or your hosting control panel. 2. Restore or Upload: If the file is missing, restore it from a backup or upload a fresh copy from another WHMCS installation that includes it. 3. Check Theme Compatibility: After upgrading WHMCS or changing your theme, the new theme may lack the file. Revert to a previous theme or choose one that includes the necessary functionality. If you're using a custom theme, you may need to create the missing captcha.tpl file or choose a theme that includes the required functionality. Thanks

Hi I meant on the /billing/invoice/xxxxxx page Maybe even a link to the log that filtered by invoice # would suffice.. rather than displaying the complete invoice history..

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)

The automation issue in WHMCS for additional purchases may be due to missing or misconfigured triggers for add-ons. Ensure automation is enabled for all product types and that the payment gateway is properly integrated to trigger actions after transactions. Also, check for any conflicts with other integrations, like Spotify streaming.

Here is an updated link: https://controlc.com/d0ac5777

the entry is correct, but if this is the only entry in your whois.json file, it should be... [ { "extensions": ".app", "uri": "socket://whois.nic.google", "available": "Domain not found" } ]

sure it's just there's still some work going on in the background, I still have to print domain info properly in WHMCS whois lookup and so on, well there might be some unreturned information in upcoming days cuz as I said above there's still work going on for method that whois calls, but here's the working whois that you can write in your whois.json file if you need .ge domain registration { "extensions": ".ge,.com.ge,.net.ge,.org.ge,.edu.ge,.pvt.ge", "uri": "https://whois.ns.ge:443/index.php?domain=", "available": "NO OBJECT FOUND!" }

which is the definition of a lookup provider. all i'm saying is that WHMCS 7 is designed to either use whois, or a lookup provider, for ALL TLDs - you can't mix and match, e.g this module for .ge, but whois for .com - you have to put all your eggs in one basket.