Leaderboard

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

Glad to see more customers speaking up about this… it’s a simple, fixable issue. All they need to do is keep allowing the switch: Add ($allow_adminarea_invoice_mutation = true;) in your WHMCS configuration.php . WHMCS choosing a one-size-fits-all strict model is what’s really causing the pain… let us decide if we need to deal with regional compliance and added accounting complexity, not force it on everyone.

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.

Yes, I agree they should be an option

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.

@WHMCS John If you want this to be the new default Stripe module, a migration path from the current default Stripe module will be necessary.

Yeah this is a nightmare

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.

Hello @sahostking Thank you for your message. We are aware of this issue in WHMCS 8.13.4, which is currently being tracked under case WHMCS-26568 with our development team. A hotfix has been attached to this message to address this issue for you and anyone else. Please upload and extract the contents of the attached file into your WHMCS installation directory, allowing it to overwrite the existing files. I hope this helps! WHMCS-26568-hotfix.zip

Hi everyone, I would like to share a free community addon I created for WHMCS 9.x: CW Invoice Mutability for WHMCS 9.x Repository: https://github.com/RicRey1988/cw-invoice-mutability-whmcs-9.x WHMCS 9 introduced invoice immutability for non-Draft invoices. I understand the reason behind this change from an accounting and audit-trail perspective, but I also noticed that some administrators still need a controlled way to manage invoice editing in specific internal cases, especially before an invoice is paid or before it is synchronized with an external tax/e-invoicing system. This addon provides an admin interface to manage the current WHMCS invoice mutability compatibility option without manually editing configuration.php. Main features: Enable or disable invoice mutability from the WHMCS Admin Area. Automatically add or remove the current WHMCS compatibility flag: $allow_adminarea_invoice_mutation = true; Create a backup of configuration.php before modifying it. Optionally hide the WHMCS Admin Area warning banner about invoice immutability being disabled. Advanced/emergency mode to convert eligible Unpaid invoices back to Draft. Audit log table with invoice snapshot, invoice items, transactions, admin ID, IP address, reason, and timestamp. Safety checks to block Draft conversion when the invoice has transactions, payment date, or possible external/tax authorization references. PayPal donation link included for anyone who wants to support the project. The advanced Draft mode is intentionally restricted. It is not intended for already-paid, fiscalized, externally authorized, or tax-reported invoices. In those cases, the correct workflow should normally be credit notes, cancellation, voiding, or re-issuance according to local accounting rules. Installation: The folder must be named exactly: cw_invoice_mutability Final WHMCS path: /modules/addons/cw_invoice_mutability/ Required structure: modules/ └── addons/ └── cw_invoice_mutability/ ├── cw_invoice_mutability.php ├── hooks.php ├── README.md └── lib/ └── CwInvoiceMutabilityTools.php You can clone it directly with: cd /path/to/whmcs/modules/addons git clone https://github.com/RicRey1988/cw-invoice-mutability-whmcs-9.x.git cw_invoice_mutability Then activate it from: Configuration > System Settings > Addon Modules After activation, go to: Addons > CW Invoice Mutability This addon is free and community-oriented. It is not affiliated with WHMCS. If it helps you, donations are welcome: https://paypal.me/hostingsupremo Feedback, improvements, and pull requests are welcome.

I’ve added: $allow_adminarea_invoice_mutation = true; Honestly, this change is a nightmare for our daily workflow. We need to edit invoices every day, and with this new restriction, what used to be a simple operation has become an everyday problem. In my opinion, this was a very bad decision from a usability point of view, especially for companies that manage billing operations daily and need flexibility when handling invoices.

Not everyone wants SAAS solutions, or keeping data with a third party due to concerns about client data. I'm one of those businesses.

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

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.

Whats stupid is as a developer this is as simple as adding a checkbox to the config to allow us to choose ourselves. I've never in my life understood why software companies lock you in, instead of giving you the option. You keep increasing prices year after year and you want us to stay with you, but if you keep doing this crap most of your base is not gonna find value in your ever increasing prices.

Welcome to the common sense reasons why were frustrated about WHMCS enforcement of preventing us from editing our OWN invoices we created in the first place. Credit / debit is useless in real world standard practice. If they want to provide a switch to disable editing published invoices or changing status fine, but dont force it on the customer base. That's dumb.

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;

Thank you for the terrible WHMCS support. This is now the tenth client who has made a bulk payment and the late fee is simply not added to the invoice, and none of the outstanding invoices are automatically marked as paid. I’m not even going to mention the credit and debit issues anymore, because it seems the WHMCS developers themselves don’t even know what they’re doing. Does anyone have a suggestion for another system similar to this garbage?

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.

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

WHMCS support have told me recently that they're focusing on support tickets, and this community is not a good way to obtain support. Send a support/bug report and include the URL to your post and they will reply. Would be great if you post the reply here too. Will most likely be a case/bug number for a future release.

@WHMCS John Good news. Thanks. Are there any screenshots of the new client UI/Nexus/Search/Ordering etc.

So after we have been told to rather use the Add Payment method instead for every single individual invoice, up to now for 15 years I have ALWAYS used the "Mark Paid" option for bank transfers as this is genuinely helpful when you have 5 invoices that need to be marked as paid. Now I have to edit every single invoice and mark them paid manually. What a MESS!! But now how do we fix the invoices that have credit notes added to them that are not being included in the reporting that were all marked with "Mark Paid" button? We can't edit the invoice after it has already been marked as paid and emails and invoices receipts have already gone out to clients! Did you manage to rectify the ones that have credit notes and were marked paid using the "Mark Paid" button so it shows in the financial reports? Do we just mark them as UNPAID and then add a payment? or what?

Hi everyone, I am happy to share a complete, community-maintained Bengali language translation pack for WHMCS. This project aims to provide a native language experience for WHMCS users in Bangladesh and Bengali-speaking users around the world. This language pack covers the full WHMCS Client Area, as well as the Admin Area strings, making it fully localized for local business needs. Features: Full localization of Client Area. Admin Area support. Community-maintained and regularly updated. Easy installation and integration. You can access the project on GitHub: https://github.com/Mojib-Rsm/whmcs-bengali-language How to Install: Download the bengali.php file from the repository. Upload it to your WHMCS installation directory under /lang/. Activate it from Setup > General Settings > Localisation in your Admin Area. I welcome your feedback, suggestions, or contributions. If you find any typos or missing strings, please feel free to open a Pull Request on GitHub. Happy localizing! Best regards, Mojib Rsm Portfolio: mojib.me

As with most discussion boards, it's a member to member conversation for the most part. Staff do participate, but there doesn't seem to be a dedicated effort in that regard. I also imagine there are some strict guidelines they have to follow so none say "the wrong thing" and cause issues. Very low participation as a result, and I'd guess a low priority to do so.

@WHMCS John Can you please clarify?

I did find that I can manually change the status to Draft in the database and then I can edit the invoice and then publish it again.

We waited for V 9.0.2 in the hope that it will have no issues, and had the misfortune of upgrading. And since then spent an entire day trying to get it to work and it does not work. Issue 1: When you add a product to the Cart", the Nexus Cart shows empty with this warning: "error has occured" (screenshot below) Issue 2: I renamed nexus_cart to nexuscart, and then the Cart showed the product added to it, but several warning appeared on screen: "Internal Error. Try again later". (screenshot below) Issue 3: When you try to increase the number being ordered (1 to 2), you get another error: "invalid product/item ID". (screenshot below) Issue 4: When you try to remove the product by clicking the Trash icon, the product doesn't get removed. Issue 5: When you click Checkout, you encounter the same "internal error. try again". warning. Issue(s) 6: There are so many CSS issues and white spaces problems on the Nexus template and Nexus cart, which require endless customisations to fix. And, now cron has run, and we can't revert the backup and have to figure out another way to revert to previous version. Seriously, how can we rely on whmcs to bill our customers? More issues below: (8) When you activate Nexus Template and Nexus Cart, on Small screens (mobile and tablets), the Navbar becomes Hamburger menu (which is the correct behaviour), but it leaves massive White Space in the Navbar's place. That destroys the look of the product and other pages on whmcs. (9) I activated "Standard Cart" due to the previous issues, but when you add a domain and another product to Standard Cart, the Cart only shows Product and not the domain name. I think the same issue occurs on Nexus Cart too.

As product manager, I should think he has more pressing responsibilities than this community. Busy with that job, vacation, who knows?

Definitely disable autoupdates 😧

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

@RadWebHosting's recommendation here is brilliant, and would be my suggestion too! Of course, you can also see a list of all overdue invoices at Billing > Invoices > Overdue in the Admin Area. If you'd be interested in a new event being added to your Notifications settings for when an invoice becomes overdue, I'd recommend opening a feature request here: https://requests.whmcs.com./ I can absolutely see how this would be useful, so getting that feature request open will allow others to comment on and vote for your request. Hope this helps :-)

Hi guys, I have the following case, I'm applying the invoicepdffooter.tpl and quotepdffooter.tpl, the content is shown on both Invoice and Quote generated PDF, but in case the PDF contain multiple lines (services) then the footer is over the invoice/quote services, like in the screenshot below. Is there any chance I could have a restriction in place for the invoicepdf.tpl and quotepdf.tpl as soon as it reaches the footer area to create a second page? thanks, Alex

Hi @rcartists, This error is typically caused by an syntax error in a template customisation, after-market module or action hook. 1. To look for template errors, follow these steps: https://docs.whmcs.com/troubleshooting/general-troubleshooting/empty-pages/ 2. If the problem persists follow these steps to troubleshoot other customisations: https://docs.whmcs.com/troubleshooting/general-troubleshooting/blank-or-partially-rendered-pages/#oops-or-blank-pages-elsewhere

You can remove the Edit with Sitejet Builder link from the left sidebar menu under the Actions sidebar when logged in as a client and looking at the Product Details page using this hook code: <?php use WHMCS\View\Menu\Item as MenuItem; add_hook('ClientAreaPrimarySidebar', 1, function (MenuItem $primarySidebar) { $actionsMenu = $primarySidebar->getChild('Service Details Actions'); if ($actionsMenu instanceof MenuItem) { foreach ($actionsMenu->getChildren() as $child) { if (strpos($child->getLabel(), 'Sitejet') !== false) { $actionsMenu->removeChild($child->getName()); } } } }); See the attached screenshots showing this custom hook file in place in the /includes/hooks/ directory. The screenshots show that this link is no longer there after this hook code is added. You would create a file named "remove_sitjet_link.php" and add the above code into it, and upload it to your /includes/hooks/ directory. I tested this with WHMCS version 8.13.1. I hope that this helps someone.

Hey @pikerr are you sending to a department or to an email address?

Please please do not use IP as a way to detect language, 1. it is not very reliable and 2. is actually quite offencive for people who don't speak the native language of the place they live. (e.g. I am English but happen to live in Italy but don't speak good Italian and I hate it if I am redirected to the italian site even though my browser language setting is english.) Much better and much simpler is to just use the browser language setting. Here is the PHP script we use to redirect customers to our specific language pages. <?php if(isset($_SERVER["HTTP_ACCEPT_LANGUAGE"])){ $langarray=explode(",", $_SERVER["HTTP_ACCEPT_LANGUAGE"]); $lang = strtolower($langarray[0]); //echo $lang . " / " . $_COOKIE["Lang"] . " / "; $stop=0; //change this to 1 to disable redirect if ($_GET["stop"]!=1&&$stop!=1){ if (isset($_COOKIE["Lang"])){ if ($_COOKIE["Lang"]=="italian"){ header("Location: " . $_SERVER["HOST"] . "it/"); } else { header("Location: " . $_SERVER["HOST"] . "en/"); } } else { switch ($lang){ case "en-au": case "en-bz": case "en-ca": case "en-029": case "en-gb": case "en-in": case "en-ie": case "en-jm": case "en-my": case "en-nz": case "en-ph": case "en-sg": case "en-za": case "en-tt": case "en-us": case "en-zw": case "en": case "gd": case "ga": case "ga-ie": case "cy-gb": case "cy": header("Location: " . $_SERVER["HOST"] . "en/"); break; case "it": case "it-ch": case "it-it": header("Location: " . $_SERVER["HOST"] . "it/"); break; case "es": case "es-es": case "es-ar": case "es-ve": case "es-bo": case "es-cl": case "es-co": case "es-cr": case "es-do": case "es-ec": case "es-sv": case "es-gt": case "es-hn": case "es-mx": case "es-ni": case "es-pa": case "es-py": case "es-pe": case "es-pr": case "es-us": case "es-uy": header("Location: " . $_SERVER["HOST"] . "es/"); break; } } } } ?> As you can see it checks to see if a "Lang" cookie is set and uses that as the clients language if it is, thus allowing the visitor to override the script on future visits if your site sets this cookie from a language choice in the site. Otherwise it looks at the browser language choice to picks the preferred language and defaults to english if it can't find a match.