Leaderboard

Hi all, Thanks very much for your feedback on the invoice immutability and credit/debit notes implementation in v9.0. We heard you loud and clear, and I'm pleased to say that in v9.1 we have implemented an admin-configurable Invoice Immutability setting. You can enforce invoice immutability, relax it while keeping billing notes, or turn it off entirely. For more information check out our release highlights, try it out yourselves, and share your feedback in the v9.1 Beta Discussion Board

Can't say I agree there. This will likely bite you at some point, badly.

@WHMCS Carlos I appreciate the extension to keep 8.13.x going because IMO it's the most stable of the actively supported versions. Being given 1 month to upgrade DURING the start of the busy Holiday season and End of Year is not easy at all. Aside for no more bug fixes or security updates, what's the downfall to continuing to use v8.13.x ? Where was the email to alert your users? Everyone is different and I can't imagine all of your users constantly check the Documentation or the Forums.

Automatic MarketConnect Account Registration: If your install isn't linked to a Marketplace account, 9.1 now attempts to create one during upgrade, with a starter credit applied. WHMCS has now reached a this point. I'm sure the community cannot wait for this highly requested feature. 🤣 it's clear that WHMCS is now at the stage of milking the software and community as much as possible.

My concern is less the feature itself and more how it is done. Creating a Marketplace account automatically during an upgrade, with a credit applied, means a third-party account is being created on behalf of the license owner without them clicking anything. For many of us, upgrades run on production systems, sometimes with several people involved, and some providers have rules on what information can be shared with outside services. A few questions that I think the WHMCS team should answer clearly: - Is there an opt-out or a confirmation step before the account is created? - What exact data (email, domain, license details) is sent to create it? - Is the account tied to a person or to the license, and what happens to it if we do not want it? If this is opt-in with a clear screen and a plain explanation, it is a convenience. If it happens silently, it is just another reason for people to distrust upgrades, especially with unattended updates coming in 9.1.

So you're disregarding the candid feedback, why bother seek it? Will there be a way to close this automatically created account and disconnect from the service? The credit is useless for any business that does not want to use anything from MarketConnect. Also, $50 is token at best. You're correct about busy admins but present this as an option during the update install. We all focus during an update. Options like, Yes, No, Remind me later, are sensible and provide admins the choice.

We've deliberately remained on WHMCS 8.13 due to the numerous issues with version 9. We've been closely monitoring the WHMCS End of Life (EOL) schedule, where the end-of-support date for version 8.13 has been listed as "TBD" for a long time. When I checked the page today, I was genuinely shocked to discover that the status had changed: support for WHMCS 8.13 is now scheduled to end on December 1, 2026 - roughly one month from now. I checked the page earlier this month, and the date was still listed as TBD. Furthermore, the latest available snapshot on the Internet Archive, dated September 30, 2026, confirms that the status was still TBD at that point. Announcing the end of support for a major software version with only around one month's notice is completely unreasonable. This is particularly concerning given the significant issues that still remain with WHMCS 9, which are precisely why we've continued to run version 8.13 in the first place. Customers need adequate notice to plan, test, and execute a major upgrade - especially when the proposed upgrade path involves a version that continues to present substantial problems. Changing the EOL status from "TBD" to a firm date so close to the deadline, without meaningful advance notice, is simply unacceptable.

I don't think that's the entire reason. Version 9.0 was forced into GA way quicker than any version and it was full of bugs. I appreciated WHMCS decision to extend support for version 8.13 indefintely. We tried running v9.0 on a dev installation but even without any customization, we had a lot of issues. Stuff that were outright illegal and stuff that broke invoicing for EU business. We don't appreciate being given only 1 month of warning - and I'm generous when I say we were given a warning. The only reason I know support for v8.13 ends in ~1 month is because I check the docs regularly. There is no way we can make sure we're running v9 in 1 month. Usually, we're pretty quick to upgrade, but the fact that v9 was originally shipped with so many issues is concerning - so we need a lot of time making sure everything is working correctly; not just customizations, but also invoicing.

Well, not keeping me on 8.13, but yeah, that forced marketplace account notion should be removed from *all* versions.

Hi Dennis, and everyone following this thread. The date did not come out of nowhere, so let me give you the history, and then the part we genuinely got wrong. 8.13 went GA on 7 May 2025. Our published Long Term Support policy gives a minor version Important and Critical updates for one year, and 8.13's end of life was listed on docs.whmcs.com as 31 May 2026. We did not hold that date. Customers asked us to keep 8.13 alive, and the reason behind almost every request was 9.0 making invoice immutability and credit notes mandatory, with no way to turn them off if you run cash-basis accounting or manage credit notes in a third-party system. That was a fair objection. Everyone who asked was given the same answer: we would hold 8.13 until 9.1, because 9.1 was where the fix was going. That is what we did. 8.13 has had around 18 months of support instead of the 12 the policy sets out. 9.1 shipped on 20 October and carries that fix. Invoice immutability is now a three-state control at General Settings > Invoices: - Full compliance: immutability enforced, billing notes generated. This is the default. - Immutability disabled, billing notes still generated. - Immutability disabled and billing note generation turned off entirely. The third state puts you back on the pre-9.0 behaviour, and it applies to the API as well as the admin area. So 1 December is us doing what we said we would do, on the release we said we would do it on, and I am holding it. I cannot run two release trains indefinitely: every fix has to be made on the oldest supported branch and carried forward, and that time comes straight out of the 9.x work this thread is really asking for. Where we did fail you is in telling everyone. The people who asked for the extension were told the terms. Everyone else got "TBD" sitting on a page for six months and then a date appearing with no announcement in front of it. If you were not one of the people in those conversations, your reading of this is entirely reasonable, and that is on us. So, one commitment. No more TBD. Every supported version carries a real end of life date on the documentation page, and if we change one you will hear it from us here, with the reason, rather than finding it in a page diff. The TBD is what turned a decision we made in April into a surprise in October, and that is the part I am fixing. One practical note if you upgrade: check General Settings > Invoices first. The setting does not guess what you want. If something else in 9.0 or 9.1 is keeping you on 8.13, message me here directly and I will look at it. Carlos

excuse me, but wat Marketplace accounts is a requirement now even for installations not using it? Out of all the stupid things WHMCS has done, this is probably the most stupid. Well, maybe right after voiding the lifetime licenses.

That is a very valid point regarding the conflict between privacy regulations (GDPR) and financial auditing requirements (like tax and accounting retention laws). Anonymization / Data Redaction is indeed the industry standard for balancing this. Instead of a hard destroy, the module can pseudonymize the client profile—stripping out personally identifiable information (PII) like names, emails, addresses, and phone numbers while preserving the isolated financial invoices, transaction rows, and tax logs required by law. We can introduce this as an advanced "GDPR Anonymize / Redact" mode alongside the existing Close and Delete options in the upcoming release.

Hi there, CVE-2026-109618 and CVE-2026-109619 are vulnerabilities in the PHP interpreter itself, not in WHMCS. No WHMCS code is affected, and no WHMCS patch is required. The remediation is entirely at the PHP level, so this must be addressed by you or your hosting provider through PHP updates. Impact Any server running an affected PHP version may be vulnerable regardless of the application being hosted. Therefore, you should consider your WHMCS server affected until the underlying PHP installation has been updated. What you need to do Please update to the patched PHP version for your branch as soon as your operating system vendor, control panel provider (for example cPanel EA-PHP, CloudLinux, Plesk), or package repository makes the update available. After updating PHP, be sure to restart any relevant services, such as PHP-FPM, Apache, or Nginx, as appropriate for your environment. While no WHMCS changes or updates are required to mitigate these vulnerabilities, updating PHP is required. Please work with your server administrator or hosting provider to ensure that all affected PHP versions on your server are updated as soon as practical. Feel free to contact us if you have any questions or concerns.

Oh hell, I misread that, so editing in full. Not accepting the EULA generally halts the upgrade in most software. This means we MUST accept to upgrade, and doing so creates the marketplace account? Read the room, John. No one asked for this, no one other than your company/Webpros and so on want it. Bad thing to force.

Hi all, I'm happy to provide some details which you will see in the beta today. Upon upgrade to 9.1 a Full Administarator will be prompted to accept the updated EULA - with a prominent summary of what's changed. Nothing happens without accepting the EULA and junior roles cannot accept it. Accepting creates a MarketConnect account for this installation using the name and email address of the Full Administrator and the Company Name from System Setting and confirms your agreement to the WHMCS Marketplace Terms of Service. Accepting does not purchase or activate anything, you choose any products yourself. No data is transmitted to a third party until your first non-Webpros service is ordered and provisioned.

Well Another year another price increase. we just got this email 17.70% price increase thats 180,48 USD Extra per year. Source: WHMCS Customer Licensing Guide 2027 - WHMCS we only use WHMCS as a client management system we dont do payments via WHMCS. There has to be a cheaper alternative to this?

Hi all, Thanks for the candid feedback. The beta is a chance for us to hear your feedback before release. First, the thing we most want to be clear about: your client area is, and will stay, fully under your control. Nothing appears to your customers until you activate a service. What you offer, and whether you offer anything at all, is entirely your decision. Creating the account doesn’t start selling anything on your behalf. The account creation step is no longer optional. We are enabling one connected account and one place to manage the products WHMCS can offer, instead of a setup that differs from install to install. Every account also gets a $50 credit. It’s there so you can try a product without having to commit any money to it first. We also know that busy admins often never come across new options, so this puts them within easy reach. We’d welcome your thoughts on the credit and how it’s presented, and on anything else in the 9.1 beta. Every comment helps us make the release better. Thanks again!

LEGEND, thank you so much Rob

Yeah or just develop your own solution, like we did. 🙂 Not only cheaper (in the end), but also faster, more control, less bugs and (which is the best part) only include what you really use! We don't use 60% or 70% of WHMCS functions. The majoriity is for us considered as bloatware (no offence meant). But I fully understand that for the majority WHMCS is a complete solution and they lack the skills to developer their own solution. Then you have to search for alternatives and like SwiftModders stated; there are quite a few alternatives available nowadays (2026). Sidenote; everything owned by WebPros; SolusVM, WHMCS, Plesk, cPanel, etc. etc. etc. all suffer from yearly price increases. It's absurd. Back in the day (7 or 8 years ago) we had over 800 Plesk licenses. But after many years of price increases (7th price increase in a row) we are down to less than 50 Plesk licenses. Our server customers do not want to pay absurd prices (or price increases) for an interface where 80% is never used. For interface panels there is even a wider choice nowadays. And instead of paying over 500 Euro's for a Web Host Edition; we are now paying just a bit more than 1/3 a year. For almost 95% same functions. The difference in the past was Plesk support, but with AI, who needs support anymore. We don't. Our customers don't. Nobody does. My 2 cents; look around for alternative solutions, dig in and test it. In the end you can save a lot of money!

Of course, it's simply not to use the platform. However, as long as people continue to pay after each price increase, they won't change their practices. Personally, I stopped using WHMCS altogether once they dropped owned licenses. That was the end of the line for me, and the only reason I still give WHMCS any money is that they require an active license to download the latest version of WHMCS. I have many clients using my themes, so I can't simply abandon them because I don't like their business practices. But, hey, screw your community, right? I won't go advertising alternatives, but you don't have to search hard to find them.

I think WHMCS are in and have been for a while the stage of milking the software for us much short term gain as possible at the cost of the long term community and direction. I think the reality is the small hosting industry as a whole is in major decline and WHMCS are seeing the same decline so they are now just milking it dry. A bit depressing but with the rise of Wix, AI generated websites/hosting, Shopify etc the decline is going to continue.

Was coming here to ask. I don't want one, ever, as I will not use it. I'd imagine at some point this will simply show up on customer facing pages and someone will want something from it, forcing us to develop a hook to vanish it. Stop removing choice, WHMCS. This is NOT ok.

Accounting varies a lot between juristictions. As a *billing* system we want it to do basic billing well. We use accounting software for our business as there other things like payroll that need to be managed.

Trying to download ImportAssist from Marketplace (https://marketplace.whmcs.com/product/46-importassist ) Using Chrome: the download process just gets stuck, without any error message Using Edge: I got the error "ImportAssist_v1.5.3.69 (2).zip can't be downloaded securely" Using Opera or Tor: the download is completed successfully

Yes, I agree they should be an option

WHMCS uses cookies to maintain session state and store small amounts of data on visitors’ computers or devices. For detailed information how cookies are used within WHMCS, visit https://docs.whmcs.com/Cookies Besides these, you may also be using cookies for tracking and analytics, such as Google Analytics, etc. Learn below how to use an action-hook to create your own cookie consent banner, using either your favourite cookie consent platform, or custom code. Below we'll explain how you can implement your own cookie consent banner, using either your favourite cookie consent platform, or custom code. Action Hook In this example, we will use the ClientAreaFooterOutput hook point, but you can also use the ClientAreaHeaderOutput hook point, depending on your preference. <?php # Cookie Banner Hook. # Customise as needed, and place in your WHMCS's /includes/hooks folder. if (!defined("WHMCS")) die("This file cannot be accessed directly"); function cookie_banner_hook($vars) { return <<<HTML <!-- Begin Cookie Consent --> <!-- End Cookie Consent --> HTML; } add_hook("ClientAreaFooterOutput", 1, "cookie_banner_hook"); If you have your own custom cookie consent code, you would simply place it between the markers. However, for those who are starting for scratch, below are two examples for your ease. 1. Example: GlowCookies JavaScript Cookie Consent Banner GlowCookies is an open source project available at GitHub, which has been used as an example here. It offers a simple yet powerful means to implement the cookie consent banner. It is highly customisable, and below is an implementation of this, within our action-hook. You will notice that, all the required parameters can easily be adjusted within the code itself. <?php # Cookie Banner Hook. # Customise as needed, and place in your WHMCS's /includes/hooks folder. if (!defined("WHMCS")) die("This file cannot be accessed directly"); function cookie_banner_hook($vars) { return <<<HTML <!-- Begin Cookie Consent --> <script src="https://cdn.jsdelivr.net/gh/manucaralmo/GlowCookies@3.1.8/src/glowCookies.min.js"></script> <script> glowCookies.start('en', { style: 1, analytics: 'G-AA00000000', facebookPixel: '011223344556677', customscript: [{ type: 'custom', position: 'body', content: `console.log('custom script');` }], customscript: [{ type: 'src', position: 'head', content: 'https://www.googletagmanager.com/gtag/js?id=G-BB00000000' }], hideAfterClick: false, border: 'none', position: 'left', policyLink: 'https://link-to-your-cookie-policies.com', bannerDescription: 'This site uses cookies to provide necessary website functionality, and optionally, to improve your experience and analyze our traffic.', bannerLinkText: 'Read more about cookies', bannerBackground: '#c5c5c5', bannerColor: '#darkgray', bannerHeading: '<h5>We use cookies</h5>', acceptBtnText: 'Accept All', acceptBtnColor: 'white', acceptBtnBackground: 'black', rejectBtnText: 'Essential Only', rejectBtnBackground: 'eee', rejectBtnColor: 'black', manageColor: 'black', manageBackground: 'lightgray', manageText: 'Manage Cookies' }); </script> <!-- End Cookie Consent --> HTML; } add_hook("ClientAreaFooterOutput", 1, "cookie_banner_hook"); You can learn more about customizing and/or configuring GlowCookies parameters by visiting their documentation and codebase at https://github.com/manucaralmo/GlowCookies In order to implement this cookie consent banner, place this action hook in the WHMCS /includes/hooks folder. 2. Example: TempsFeed JavaScript Cookie Consent Banner However, you may also consider using the code from your favourite cookie consent builder platform, such as TempsFeed, etc. With the wizard interface, you can configure and fine-tune the settings to suit your needs, and then generate the cookie consent code, to be used in our action hook, as before: <?php # Cookie Banner Hook. # Customise as needed, and place in your WHMCS's /includes/hooks folder. if (!defined("WHMCS")) die("This file cannot be accessed directly"); function cookie_banner_hook($vars) { return <<<HTML <!-- Begin Cookie Consent --> <!-- Cookie Consent by TermsFeed https://www.TermsFeed.com --> <script type="text/javascript" src="//www.termsfeed.com/public/cookie-consent/4.1.0/cookie-consent.js" charset="UTF-8"></script> <script type="text/javascript" charset="UTF-8"> document.addEventListener('DOMContentLoaded', function () { cookieconsent.run({"notice_banner_type":"simple","consent_type":"express","palette":"dark","language":"en","page_load_consent_levels":["strictly-necessary"],"notice_banner_reject_button_hide":false,"preferences_center_close_button_hide":false,"page_refresh_confirmation_buttons":false}); }); </script> <script type="text/plain" data-cookie-consent="strictly-necessary"> <!-- Strictly Necessary Cookie Script Example --> </script> <script type="text/plain" data-cookie-consent="functionality"> <!-- Functional Cookie Script Example --> </script> <script type="text/plain" data-cookie-consent="tracking"> <!-- Tracking Cookie Script Example --> </script> <script type="text/plain" data-cookie-consent="targeting"> <!-- Targetting Cookie Script Example --> </script> <noscript>Free cookie consent management tool by <a href="https://www.termsfeed.com/">TermsFeed</a></noscript> <!-- End Cookie Consent by TermsFeed https://www.TermsFeed.com --> <!-- Below is the link that users can use to open Preferences Center to change their preferences. Do not modify the ID parameter. Place it where appropriate, style it as needed. --> <a href="#" id="open_preferences_center">Update cookies preferences</a> <!-- End Cookie Consent --> HTML; } add_hook("ClientAreaFooterOutput", 1, "cookie_banner_hook"); You can learn more about generating your TermsFeed cookie consent banner code, by visiting their website at https://www.termsfeed.com/cookie-consent/ As before, this action hook should be placed in the WHMCS /includes/hooks folder for the cookie consent banner to display. Please note: The method, format, or mode of delivery of the cookie consent, described in this article are merely code examples, and the information contained within, should by no means be construed as legal advice. You or your organisation will need to comply with new cookie warning laws that apply to your site and regulations concerning their use. Information regarding cookies used by WHMCS can be found at https://docs.whmcs.com/Cookies We are not affiliated with TermsFeed, nor GlowCookies, and have simply used these as examples, describing how to implement third-party cookie consent code (such as theirs) in an action hook in WHMCS. Further Reading https://docs.whmcs.com/Cookies https://developers.whmcs.com/hooks/getting-started/ https://developers.whmcs.com/hooks-reference/output/#clientareafooteroutput https://developers.whmcs.com/hooks-reference/output/#clientareaheaderoutput

The WHMCS.Community is intended to provide a place for users of WHMCS to discuss, share and interact with each other as well as WHMCS Staff. To ensure we maintain a friendly environment, we ask users to respect the following rules and guidelines. Please let us know via the WHMCS.Community Assitance category should you have any questions or comments, posts in this category are visible between yourself and the WHMCS.Community Team. WHMCS reserves the right to alter these rules from time to time. 1.User Accounts Each person may have (one) 1 forum login regardless of the number of companies you may be part of. Duplicate accounts will be removed from WHMCS.Community Please do not share your user account with others - each person should retain their own username and password Usernames must not be created that contain any of the items listed below: An email address A website address The following words WHMCS cPanel Staff Moderator Admin Any word determined to cause offence or be deemed inappropriate. Usernames or Users that do not comply with these rules may be removed from WHMCS.Community 2. Behaviour on the Community We expect all users to be friendly and polite. While we understand that users will disagree and have different points of view at times, this can be communicated in a civil manner Please do not post rude, insulting or inflammatory posts. Personal attacks, name-calling and insults will not be tolerated on WHMCS.Community. Profanity and inappropriate images (including porn or gross violence) may not be posted anywhere on the WHMCS.Community. WHMCS.Community Staff & Moderators use their sole discretion as to what is deemed unacceptable behaviour in the community and may remove content at any time. Your posts assist other users, please do not delete content if you find an answer, please share this solution to help other users. 3. Advertising on WHMCS.Community Advertising, offers or self-promotion are to be posted only in the Third Party Add-ons section of the community. Community users seeking to hire a developer may post within the Service Offers & Requests section. Advertising is limited to one advertisement per seven (7) day period on a rolling 7-day basis. Additional or excessive advertising will be removed by the moderation team and your ability to post in advertising boards removed. Soliciting and/or self-promotion via the private messaging (PM) system is strictly prohibited. The sale or reselling of WHMCS Licenses is strictly prohibited on the community. Affiliate and referral links may not be used, these links are those that link to a site and contain information crediting the person with that referral 4. Posting and Moderation on WHMCS.Community The WHMCS.Community is moderated by WHMCS.Community Moderators and Staff. When a post is deemed to be in breach of the rules it will be removed and the user advised via a warning. Please do not cross-post across the community. If your topic is better suited to another section one of the WHMCS.Community team will move it to the best category for you. You may report your post if you wish to have it moved by a moderator. For privacy reasons please do not post any personally identifiable information including Usernames, Passwords, Contact Numbers, Email Addresses and/or Credit Card Numbers As WHMCS.Community is a moderated community we have implemented a Warning System. When a post is removed for breaching the community rules we’ll be sure to let you know. We allocate points to a warning and once you have a set number of points you may be suspended from posting on the community. Users that do not comply with the rules for WHMCS.Community may be banned temporarily. Ongoing temporary bans may result in a permanent ban from WHMCS.Community. The public discussion of moderation decisions is not permitted, these will be removed without notice and may result in a community ban. 5. Signature and Profile Rules Your signature may include links, however, please ensure these are reasonable (no more than 4) and they must not include Referral/Affiliate links. This includes pricing and plan details Signatures may not contain more than 4 lines at a 1024x768 resolution Please do not sell or rent your signature space, your signature is yours alone. Where your signature does not comply with these rules you may be asked to alter or remove it 6. WHMCS.Community Ranks Official WHMCS Staff & Moderators are identified by one of the following ranks located below their profile image, in addition, their posts are highlighted blue WHMCS CEO WHMCS Community Manager WHMCS Customer Service WHMCS Developer WHMCS Marketing WHMCS Staff WHMCS Support Manager WHMCS Technical Analyst WHMCS.Community runs a ranking system, new community members start with the rank of Newbie and can progress based on the number of posts, reputation points and length of time active on the community Some users have a special “Super Users” rank. These members are a select group of elite community members that are long-standing mentors in the community, courteous to other members, always providing technical insight and advice, and generally helping to make our community a better place to learn, troubleshoot and advance. The WHMCS.Community ranking formula is changed from time to time and without notice. The algorithm used is not published or discussed with users to prevent gaming the system 7. Contacting the WHMCS.Community Team You may contact a member of the WHMCS.Community via the WHMCS.Community Assitance board If you would prefer to email you may open a ticket by emailing forums@whmcs.com Thank you for helping to keep WHMCS.Community a great place