All Activity

With the release of WHMCS 9.1.0, we're pleased to announce that all our WHMCS themes, client area templates, admin themes, and order forms have been updated and are now compatible with the latest WHMCS version. Our latest releases also include PHP 8.4 and ionCube Loader 15 support, along with various improvements, bug fixes, and UI enhancements. Updated Themes & Templates HostX – v3.1.2 https://whmcsglobalservices.com/web-hosting-themes-templates/hostx/ CloudX – v1.1.2 https://whmcsglobalservices.com/web-hosting-themes-templates/cloudx/ ClientX – v3.3.3 https://whmcsglobalservices.com/clientarea-template/clientx/ TwentyX – v1.3.4 https://whmcsglobalservices.com/clientarea-template/twentyx/ AdminX – v1.1.3 https://whmcsglobalservices.com/web-hosting-admin-themes-templates/whmcs-adminx/ Updated Order Forms One Step Checkout (OPC) – v2.5.4 https://whmcsglobalservices.com/custom-template/one-step-checkout-whmcs-orderform-template/ VueJS WHMCS One Step Checkout – v2.4.1 https://whmcsglobalservices.com/custom-template/vue-one-step-checkout-orderform/ What's Included? Full compatibility with WHMCS 9.1.0. Support for PHP 8.4 and ionCube Loader 15. Updated language files following WHMCS 9.x naming conventions. Improved mobile responsiveness across themes and order forms. Various bug fixes, stability improvements, and compatibility enhancements. Demo: http://demo.whmcsglobalservices.com/ We recommend all existing customers update to the latest versions to ensure smooth operation with WHMCS 9.1.0. Have questions or need assistance with the updates? Feel free to reach out to our support team.

Yes I'm on 9.1.0. Happy to provide details here. Ask away. Recent tickets (over the past 12 months) result in copy/paate replies stating that yes we are aware and it will fixed but no timeline is available. Request to escalate have been met with, no that's not possible.

An update on this topic:

Hi everyone, We have listened to feedback from the community and from our customers, and we are extending the end of life for WHMCS 8.13 from December 31, 2026 to January 31, 2027. December is a busy month for most of you, with year-end closing, code freezes and the holidays. Moving from 8.13 to 9.x is a major upgrade, and it deserves proper time to plan and test. The extra month gives you that window in January. 8.13 continues to receive security fixes until January 31, 2027. After that date your installation keeps working, but we will not release any further patches for it. WHMCS 9.1 is available now and is the version to upgrade to. Before you upgrade, back up your files and database, check your PHP version and module compatibility, and test key workflows on a staging copy. PHP 8.2 reaches its own end of life on December 31, 2026. WHMCS 9.1 supports PHP 8.2, 8.3 and 8.4, so this is a good time to move to a newer PHP version too. Update to WHMCS 9.1 before you move to PHP 8.4. The docs are being updated with the new date, and all customers in 8.13.x will receive an email confirming it.

@Damo so you are on 9.1.0, the permission is enabled, and the option still doesn't show? That shouldn't happen. Please open a support ticket so the team can look at your setup

Access is enabled. As for timing, if it's a critical security related issue then it should be patched immediately. This auto update feature is seemingly becoming more an automated tool to roll out 'features' than critical updates.

@Damo The schedule is there because many admins need updates to land in a set window, for example outside business hours or after their backups run. Set it to weekly and the gap is at most a week. When a critical security release comes out, you don't have to wait for the schedule: you can apply it straight away from Utilities > Update WHMCS.

@Damo the option is there .. please check your admin user has the permissions set for it

https://docs.whmcs.com/releases/9-1/9-1-release-highlights/#unattended-automatic-updates If you can schedule these security updates then how does that avoid something exploitable? eg. You're updates are set to the 28th of each month but the exploit is published on the 3rd. FAIL!

Yes. 9.1.0. I'm also curious to know your thoughts on what constitutes 'minor improvements' that can be applied automatically.

Are you sure you're on 9.1? https://docs.whmcs.com/releases/9-1/9-1-release-highlights/#unattended-automatic-updates

@Damo if it's every device, every browser and every admin, I'd stop looking at browser settings and check whether the cookie is actually being set and kept. This is what I'd go through: 1. Watch the login in DevTools. Open the admin login page in Chrome, press F12, go to the Network tab, tick Remember Me and log in. Click the login request and look at the Set-Cookie lines in the response headers. If Chrome rejected one, there's a small warning icon next to it, and hovering over it tells you why (Secure flag on a non-HTTPS request, SameSite, domain mismatch and so on). Then open Application, Cookies for your WHMCS host and see whether the cookie is there and what expiry it has. A cookie that shows "Session" in the Expires column instead of a future date would explain the repeated logins exactly. 2. Compare the System URL with the address your admins actually type. Under Configuration, System Settings, General Settings, the WHMCS System URL should match the scheme and host exactly (https, and www or no www). A mismatch there is one of the most common reasons login and dismiss cookies don't stick. 3. Look at anything sitting between the browser and PHP. A Cloudflare cache rule or a caching proxy that caches admin responses can drop or reuse Set-Cookie headers, and server-side hardening (an Apache Header edit rule on Set-Cookie, nginx proxy_cookie_path or proxy_cookie_flags, a WAF rule) can rewrite them. Since your other app on the same domain is fine, check whether a rule like that only matches the WHMCS path, or was added around the time you upgraded. 4. If admins also get thrown out in the middle of working, check the PHP side too: session.gc_maxlifetime for the PHP version WHMCS actually runs on, and whether anything cleans the session save path more aggressively than that. On cPanel servers each ea-php version has its own php.ini, so the value you checked may not be the one WHMCS is using. If step 1 shows the cookie arriving with a sensible expiry and then vanishing, or not being sent at all on 9.1 when it was before, that's worth a ticket with WHMCS. Attach the response headers from the login request, with the cookie values blanked out.

This is still happening. Multiple devices, multiple admin users, multiple browsers. Are there any tools or suggestions on how to track down the cause? It only started with this release. Cookies and sessions for another app on the same domain as our WHMCS continue to work without issue.

@DennisHermannsen it is the small improvements that are of concern. The definition leaves it very open. e.g. a small improvement could be something that improves WHMCS tracking and data sharing or a change to the colour of a label so that it's easier to read.

I don't see any option to disable this feature.

this issues already been sorted by updating WHMCS to verions 9.1.0 and with plesk updated to version 18.0.82 Update #2

@WHMCS Carlos I never saw this email. Did anyone else? Personally, I have no intention of getting trapped on 9.1 right now. Just a quick glance around this community tells me it still has too many bugs. Your beta period was what, 2 weeks at best? Before I could even download and install it, the GA was available.

@Michael Wilson the client-side part is covered in my reply just above (Nathan asked the same thing): cancelled invoices stay visible in the client area, the duplicate gets a new ID, and a "Replaces invoice #..." line in the Notes field heads off most of the tickets. On the recurring amount: WHMCS builds the renewal invoice from the Recurring Amount on the client's service, not from the product's current price. So changing the product pricing on its own doesn't touch existing services. Either edit the Recurring Amount on the service directly, or tick Auto Recalculate on Save on the service and save, which pulls the current product and configurable option pricing into it. The catch that usually trips people up is timing. If the next renewal invoice has already been generated (that depends on your Invoice Generation days setting under Automation Settings), updating the service won't change that invoice. It only affects invoices created after the change. So check the client's Invoices tab first: if the upcoming one already exists, fix it with the same duplicate, publish, cancel routine, and the corrected service amount takes care of everything after that.

@azzepis you're right, thanks for the link, I missed that one. It's in the Plesk Obsidian 18.0.82 release notes under Deprecated and Removed Items: 18.0.82 dropped support for XML API protocol versions older than 1.6.9.1, and the oldVersionsSupported option (in the api section of panel.ini, set to true) temporarily turns the old versions back on. Plesk itself calls that not secure and not recommended, so I'd only treat it as a stopgap. @jessasaurus that gives you a quick test. If your Plesk is on 18.0.82 or later, add that option, run the sync again and see whether the Analyse table fills in. If it does, some request in the sync is still going out with an older protocol version even though the listing response you pasted says 1.6.9.1, and that's worth adding to the WHMCS ticket along with the Module Log. Take the option back out once WHMCS ships a fix. If you're still on 18.0.81 (which is what you mentioned earlier), nothing was removed yet, so the setting won't change anything and the ticket is the way to go. Same caution as before: don't tick Import/Sync on any rows while the left side is empty.

@WHMCS Carlos I try very hard to say professional in these threads (and I don't reply a lot), but I really have to wonder what world the WHMCS management/development team lives in. The next LTS release needs to be out (for a while, so it's fully vetted, BEFORE the previous LTS is retired. LTS has no real meaning if you can't stay on a LTS release. This is pretty much exactly the opposite of what we want/need. WHMCS at it's heart is ordering/billing software. We want a very slow/stable with minimal changes (especially within the LTS track). To be honest, I can't really think of a single new feature in the last 3 - 5 years that WHMCS has put out that we have implemented. There is no way we would implement automated updates until it's been fully vetted (read that as in production for several years). The risks simply don't make sense. Simply put, we can't. From my understanding/community threads, 9.1 forces us to sign up with the WHMCS marketplace. We have compliance requirements and we need to know exactly what data is shared between our WHMCS install and the marketplace. We also need to know how this will work since we keep a development and production environment. We've had ticket RLB-418773 open since 1-Nov-2026 and have received any useful answers. This is also going to force us to do two major upgrades in a relatively short timeframe. This is a lot of work for our staff (testing, training etc.) as well as potentially frustrating to customers. WHMCS really needs to reconsider supporting 8.13 until there is a stable/vetted path to the next LTS version. WHMCS's sister company cPanel manages to support multiple versions at the same time and I have to believe their codebase is much more complex than WHMCS. My 2 cents

@WHMCS Carlos No further delays in lights of all recent comments ? Also, with the release of 9.2 in December, we are going to plan a move to a soon obsolete version, this is just chaotic. Easier from 9.1 but more work overall. With the new security paradigm of this era, it would be clearly appreciated to have a bit of cushion to proceed with the migration and possibly have us land on 9.2. I think we all understood it is due to migrate but the time brought is insufficient.

Don't miss chance to get upto 50% off on all WHMCS products. Here are the offers available during the sale: 20% OFF on monthly plans — Use code FESTIVE20 30% OFF on annual plans — Use code FESTIVE30 50% OFF on open-source code — Use code FESTIVE50

VueJS WHMCS One Step Checkout v2.4.1 – Now Compatible with WHMCS 9.1.0 Hi everyone, We've released VueJS WHMCS One Step Checkout v2.4.1, bringing full compatibility with the latest WHMCS 9.1.0. This release includes several important bug fixes, payment gateway improvements, and compatibility enhancements to ensure a smoother checkout experience. What's New in v2.4.1? Bug Fixes: Fixed an issue where invalid or non-existent gid or pid values in the URL caused the order form to get stuck on the loading screen. Users are now redirected to the order form homepage. Fixed an issue with alphabetic values provided for gid or pid in the URL query string. Fixed automatic provisioning issues when ordering cPanel products using the Stripe payment gateway. Resolved an issue affecting domain transfers. Fixed redirection issues triggered by AJAX requests from other modules containing gid, pid, and product group slug parameters. Improvements: Added compatibility with WHMCS 9.1.0. Added support for PHP 8.4 and ionCube Loader 15. Added compatibility with the latest Stripe Dynamic Payment Gateway (stripe_dynamic). Updated Ukrainian, Portuguese, and Brazilian Portuguese language files to follow WHMCS 9.x naming conventions. Improved mobile responsiveness for a better checkout experience across devices. Product Details Product: VueJS WHMCS One Step Checkout Latest Version: v2.4.1 Release Date: 04 November 2026 Product Page: https://whmcsglobalservices.com/custom-template/vue-one-step-checkout-orderform/ We recommend existing customers upgrade to v2.4.1 for the latest compatibility updates and bug fixes. Have questions or need assistance? Feel free to contact our support team.

With the release of WHMCS 9.1.0, we're pleased to announce that all our WHMCS themes, client area templates, admin themes, and order forms have been updated and are now compatible with the latest WHMCS version. Our latest releases also include PHP 8.4 and ionCube Loader 15 support, along with various improvements, bug fixes, and UI enhancements. Updated Themes & Templates HostX – v3.1.2 https://whmcsglobalservices.com/web-hosting-themes-templates/hostx/ CloudX – v1.1.2 https://whmcsglobalservices.com/web-hosting-themes-templates/cloudx/ ClientX – v3.3.3 https://whmcsglobalservices.com/clientarea-template/clientx/ TwentyX – v1.3.4 https://whmcsglobalservices.com/clientarea-template/twentyx/ AdminX – v1.1.3 https://whmcsglobalservices.com/web-hosting-admin-themes-templates/whmcs-adminx/ Updated Order Forms One Step Checkout (OPC) – v2.5.4 https://whmcsglobalservices.com/custom-template/one-step-checkout-whmcs-orderform-template/ VueJS WHMCS One Step Checkout – v2.4.1 https://whmcsglobalservices.com/custom-template/vue-one-step-checkout-orderform/ What's Included? Full compatibility with WHMCS 9.1.0. Support for PHP 8.4 and ionCube Loader 15. Updated language files following WHMCS 9.x naming conventions. Improved mobile responsiveness across themes and order forms. Various bug fixes, stability improvements, and compatibility enhancements. Demo: http://demo.whmcsglobalservices.com/ We recommend all existing customers update to the latest versions to ensure smooth operation with WHMCS 9.1.0. Have questions or need assistance with the updates? Feel free to reach out to our support team.

@DennisHermannsen Unattended Automatic Updates only apply updates for the version you are on that we have marked as safe to apply automatically: security fixes, bug fixes and small improvements, with nothing that requires changes to your hooks, themes or customisations. Anything that needs manual steps is not applied automatically, and moving to a new version (9.1 to 9.2) is always a manual update. Before each update, WHMCS backs up the files it is about to replace and restores them if the update fails. @Damo fair enough, it's your call. You can keep automatic updates off, or set your own schedule, under Utilities > Update WHMCS > Configure Update Settings.