All Activity

It’s mentioned in the last changelog https://docs.plesk.com/release-notes/obsidian/change-log/

That output helps a lot. The response comes back with version 1.6.9.1 and status "ok" on the webspace results, so Plesk is returning your subscriptions, and 9.0.9 is already talking the new protocol (the 1.6.9.1 update shipped in 9.0.9 as WHMCS-27404). So the empty left side isn't Plesk hiding accounts. WHMCS is getting a valid list back and not turning it into rows on the Analyse screen. On the panel.ini idea: I couldn't find oldVersionsSupported anywhere in Plesk's documentation. The [api] options Plesk documents are things like enabled, allowedIPs and deprecationWarning. And since your requests already go out as 1.6.9.1, a setting for older protocol versions shouldn't change anything here. If you want to try it anyway, back up panel.ini first and take the line out again if the sync still comes back empty. What I'd do next: 1. Open a ticket with WHMCS and attach the full Module Log entries for one sync run (request and response), with usernames, passwords and domains redacted. A valid 1.6.9.1 response with status ok and an empty Analyse table is exactly the evidence they need. Mention WHMCS 9.0.9 and Plesk Obsidian 18.0.81 Update 6. 2. While you wait, check /var/log/plesk/panel.log around the time of the sync. If one of the WHMCS requests is being rejected by Plesk's XML schema validation, it shows up there even when the main listing call succeeds. 3. Test create, suspend and unsuspend on one test service. The sync screen is only a reconciliation tool, so if those still work you can carry on normally and treat Plesk as the source of truth until there's a fix. And still don't tick Import/Sync on any of those rows while the left side shows nothing.

Can't really say it much better than this. Very business-unfriendly move of WHMCS to be fast-tracking the end of support without notice, which happens to coincide with historically busy BF/CM and end-of-year. What other obstacles can we jump through by end of year?

@WHMCS Carlos I appreciate trying to work with us, but extending it until the end of December is like not extending it. December is one of the the busiest months. There's discounts, more clients, the holidays. We'll work with what we got, I guess.

I migrated from modernbill 🙂

Other than the fact that there is no clear patch to the next LTS (which we assume will be 9.1, but it's not announced) this thread basically appears to be moot as WHMCS has (at least to us) sent out an email announcing this. The fun part will be to see if history repeats itself. "Back in the day" (prob. way before most community members) ModernBill was the popular web host billing software. They released a very unpopular major upgrade and shortly after that, WHMCS because the popular choice.

So 8.13 and 9.0 are both LTS and they both get EOL at the same time? 9.0 is not getting even a full year, quere is the "long" in the LTS? 😞 1 year 7 months LTS for 8.13 11 monts LTS for 9.0 It makes no sense to label all versions as LTS and then EOLing them all. Once again, I'm very disappointed

@WHMCS Carlos Nope, exactly in the same position we were before. Not really sure why a company that puts out billing related software can't understand that ending support at year end is just not a good idea. So, for us, we either need to upgrade in November, get a management exception to upgrade during year end or risk not updating (not really an option). The path forward is pretty mirky also. 8.13/9.0 are both labeled at LTS with a 2026-12-31 date. What is the next LTS release going to be?

It's because WHMCS developers do not wnat to do nothing after plesk changed it's API. Add this in Plesk in the Panel.ini editor as workaround: [api] oldVersionsSupported = true

We have extended 8.13 support to 31 December 2026, and the email notice went out to all customers today. I hope this takes some of the pressure off the upgrade. I understand this won't be ideal for everyone. To be clear on what the date means: your 8.13.x install keeps working after 31 December. We simply won't release any further patches for it, including security fixes. Going forward, every supported version will have its EOL date published. No more TBD.

from the list accounts response i see the following Array ( [@attributes] => Array ( [version] => 1.6.9.1 ) [webspace] => SimpleXMLElement Object ( [get] => SimpleXMLElement Object ( [result] => Array ( [0] => SimpleXMLElement Object ( [status] => ok [filter-id] => 1 [id] => 1 [data] => SimpleXMLElement Object ( [hosting] => SimpleXMLElement Object ( [vrt_hst] => SimpleXMLElement Object ( [property] => Array ( [0] => SimpleXMLElement Object ( [name] => seo-redirect [value] => none ) [1] => SimpleXMLElement Object ( [name] => ftp_login and more like that in it wont send all of it as it has usernames and password in it as shown in the images i posted plesk is fully up to date!!! (Plesk Obsidian 18.0.81 Update #6) and running WHMCS version 9.0.9 this is the requests WHMCS is sending for list accounts <?xml version="1.0" encoding="UTF-8"?><packet version="1.6.9.1"><!-- Copyright 1999-2016. Parallels IP Holdings GmbH. --> <server> <get_protos/> </server> </packet> <?xml version="1.0" encoding="UTF-8"?><packet version="1.6.9.1"><webspace> <get> <filter/> <dataset> <hosting/> <subscriptions/> </dataset> </get> </webspace> </packet>

One thing in your output matters more than the matching: the left-hand (Module/Server) side ends with "No Records Found". That means the sync didn't get a single account back from Plesk, so this isn't a username or domain mismatch. WHMCS is getting an empty list, and Test Connection succeeding only proves the login works, not that the account list call returns anything. Before anything else, don't tick Import/Sync on those rows and continue. For services that exist in WHMCS but not "on the server", the sync terminates them in WHMCS and sets them to Terminated, so you'd mark 10 live customers as terminated. What I'd check, in this order: Configuration > System Logs > Module Log: enable logging, run the sync again, then open the Plesk entries. Look at the response to the account/subscription listing request. If it's an XML error (permission denied, protocol version, parse error), that's your answer. If it's a valid response with no results, go to step 2. On the Plesk box, run plesk bin subscription --list and confirm these domains are really subscriptions on that server, not domains added under one subscription (additional domains don't show up as separate accounts). Make sure the hostname/IP on the WHMCS server record is this Plesk server. If it points at an old or different server with the same admin login, Test Connection passes and the list is still empty. The Module Log request URL shows exactly where it's going. Check the WHMCS and Plesk versions. The current module needs Plesk Onyx 17.8 or Obsidian 18.0+. If the Module Log shows a clean response that does list the subscriptions and the left side is still empty, that's a module bug. Open a ticket with WHMCS and attach the log entry with the credentials and domains redacted.

What you're seeing is the "Domain Expiry Status Update" behaviour in v9. When a domain expires with its renewal invoice still unpaid, the cron cancels that invoice (or just the domain line if the invoice has other items on it) and issues a credit note for it. So by the time the client paid a week later, WHMCS had already written the renewal off, and you end up with a credit note plus a payment for the same thing. You can't delete a credit note, but you can clean it up: 1. Open the credit note (Billing > Credit and Debit Notes, or the Reference column in the invoice Ledger). If it still has a remaining balance, close it. Per the docs, closing a credit note with a balance creates an offsetting debit note, so it stops being picked up by the next invoice. 2. If it's already been applied to the next invoice, remove the applied credit from that invoice. That generates a debit note for the amount and puts the balance back where it should be. 3. Check that the domain itself actually renewed and the expiry date moved. When the payment lands after the cancellation, I wouldn't assume the renewal went through on its own. If you'd rather WHMCS stopped creating billing notes altogether, the switch is Configuration > System Settings > General Settings > Invoices > Invoice Immutability. The option "Immutability and billing note generation disabled" goes back to the old behaviour: no credit/debit notes, cancellations and overpayments go straight to the client's credit balance. Before you change it, check with your accountant whether you need credit notes for tax reasons (EU/UK VAT usually does). It also won't change notes that already exist. Also worth updating to 9.1 if you're on 9.0.x. The 9.1 release notes list several fixes in this area, such as cancelling an invoice now returning partial payments and applied credit to the client's balance, and removing credit no longer flipping a paid invoice to Refunded. Docs I went by: Credit and Debit Notes and Configure Invoice Immutability, both under docs.whmcs.com/9-1/billing-and-invoicing/.

Another addon that should be standard feature - and was even hinted about a while back by WHMCS with the release of 7.8 in 2019 when it started to support multiple saved cards.

Thanks for checking the logs, that narrows it down a lot. If both rows come from stripe_dynamic.php and that's the only endpoint, it isn't leftover config on your side. The module is recording the decline from the charge attempt and then recording the charge.failed webhook as a second event for the same attempt. I'd still put that in a ticket with WHMCS, with the two gateway log entries for one invoice attached, so it gets fixed in the module rather than everyone working around it. On dropping that event: whether it's safe depends on what you take through Stripe. For card payments that WHMCS attempts itself (the cron capture, or a client clicking Pay Now), the decline comes back in the API response right away, so the webhook only repeats what WHMCS already knows. Where the webhook earns its keep is a payment that fails later, after the charge call has already returned, like an ACH or SEPA debit that bounces a few days on. Without it, as far as I can tell, that invoice would just stay unpaid with no failure email and nothing in the gateway log, and you'd only spot it in the Stripe dashboard. So if you're cards only, removing it is a reasonable stopgap. Run one test with Stripe's generic decline test card (4000 0000 0000 0002) and one successful payment to confirm you get one failed row, one email, and paid invoices still go through. If you offer bank debits, I'd keep the event and stop the duplicate email with an EmailPreSend hook instead. Either way, make a note to add the event back once WHMCS ships a fix.

QHN-813044

This module is still fully compatible with latest WHMCS versions. Feel free to contact us if any questions or concerns prior to ordering!

Have you considered updating the CC field of the email template directly in the database before calling the SendEmail API? Since WHMCS already stores the CC recipients with the email template, you could potentially update that field with the required email addresses before sending the email. The SendEmail API would then use the updated template configuration. However, this approach would need testing, especially if multiple emails are sent simultaneously using the same template, as it could cause recipient conflicts. For fixed CC addresses, configuring them directly in the email template should be sufficient. For dynamic CC addresses, a database-based approach might be worth exploring.

The logs are showing both these entries are coming from the new Stripe Dynamic Payments module. The only endpoint is stripe_dynamic.php. We also updated to the latest Stripe API version for testing. We did find that removing the payment.failed destination event from within Stripe stops the "failed" WHMCS entry and the declined charge entry still shows. We are still testing to see whether this causes an issue as having 3 destination events seems to be the default. Is anyone using charge.failed, charge.succeeded, and payment_method.updated as destination events and not seeing the "failed" entry on declined payments?

That seems unlikely, with the product itself being EOL'ed almost 10 years ago. Before they ended the support and updates "product", it was a fairly expensive thing. Though not impossible they bought a pile of them, I'd think that's not plausible, especially since they'd likely have updated since if they could have. Maybe.

That "resolving to the wrong IP" line is a bit of a red herring. The curltest script compares the lookup against a short list of IPs hardcoded into the script, and that list has gone stale more than once over the years as WHMCS moved its licensing infrastructure. 104.20.36.75 and 172.66.151.35 are exactly what whmcs.com resolves to from anywhere right now, so your server's DNS isn't being hijacked. Don't let anyone "fix" it by pinning whmcs.com to another IP in /etc/hosts; that's the one thing that really would look like a bypass. What I'd check, in this order: 1. Can the server actually complete an HTTPS request to WHMCS? From SSH as the user WHMCS runs under, run: curl -sv https://www.whmcs.com/ -o /dev/null On a box old enough to still run WHMCS 6 (PHP 5.x era), the usual failure is the TLS handshake or an outdated CA bundle, not DNS. If curl from the shell works but PHP's curl doesn't, the PHP build's OpenSSL is the problem. 2. Log in to your account at whmcs.com and look at the license itself: status Active, and the Valid Domains/IPs/Directory match where the install lives now. If the server IP changed recently, a reissue from the client area clears that. 3. If both of those are fine, open a ticket with WHMCS licensing, give them the license key, and ask straight out whether 6.x installs can still validate against the current licensing servers. They can see the failed check attempts on their side, which beats guessing. On the upgrade question: whatever the root cause turns out to be, 6.x is many years past end of life and only runs on PHP versions that stopped getting security fixes a long time ago, so plan the upgrade either way. With an owned license, check whether your Support & Updates is still active; if it lapsed, you'll need to renew it before you can download current versions. Do the jump on a copy of the site and database first, since going from 6 to current means moving through several major versions and PHP versions, and any custom templates or old modules will need checking along the way.

Yes, using a hook would be a better solution if WHMCS does not address this issue. However, I believe this should be fixed in an upcoming WHMCS release.

Nice find on the Chrome password manager, d9hosting. That also explains why some people never see it: it only hits staff who have the admin login saved in Chrome. One suggestion on ThemeMetro's fix: rather than editing viewticket.tpl in the Blend template, drop the same script into a hook. Template edits get overwritten on the next WHMCS update, while a file in includes/hooks/ survives updates and you don't have to remember to re-apply it. Something like this: <?php // includes/hooks/ticket_status_autofill_fix.php add_hook('AdminAreaFooterOutput', 1, function ($vars) { if (basename($_SERVER['SCRIPT_NAME']) !== 'supporttickets.php') { return ''; } return <<<'HTML' <script> // paste ThemeMetro's script body here, from "// Prevent Chrome Password Manager autofill" down to the setTimeout lines </script> HTML; }); Their script already returns early when the status field isn't on the page, so it's harmless on the ticket list. After adding it, hard refresh a ticket (Ctrl+Shift+R) and check the status box no longer gets the username dropped into it. Worth adding d9hosting's finding to a WHMCS ticket as well, so the status field markup gets fixed in core, since this affects anyone using Chrome's built-in password manager.

WHMCS 8 removed the ability for administrators to change a user's password from the admin area. Change User Password puts it back, safely and with every action recorded. Change a password straight from the client profile or from the Manage Users dropdown, generate a strong password with one click, and optionally email it to the user so they can log in right away. Owned License ($30.00) - https://www.hardsoftcode.com/cart/link/change-user-password-for-whmcs/owned Source Code License ($200.00) - https://www.hardsoftcode.com/cart/link/change-user-password-for-whmcs/source Why you need it Users ask support to reset their password, and WHMCS no longer lets you do it. Staff can reset passwords without ever needing the old one. Every change is logged with who did it, when and from where. Highlights Two places to change a password: the client profile tab and the Manage Users dropdown, using the native WHMCS modal. Built-in password generator: configurable length (8–64) and character types, using a cryptographically secure random source. Optional email to the user: sent with a ready-made Change User Password template. Dashboard and activity log: KPI cards, a reset trend chart, and a full audit trail with IP and browser. Role-based access: uses the built-in WHMCS Access Control list, enforced server side. Secure by design: POST-only, CSRF-protected endpoints, and no passwords in the logs. Works on WHMCS 8.x and 9.x. Admin area only, no client-area changes. What's New This release makes the module's modal endpoints POST-only with CSRF validation. Opening an endpoint URL directly in the browser now returns the standard WHMCS HTTP Method Not Allowed page, just like WHMCS core routes. CSRF checks also go through one shared, fail-closed helper, so the modal shows a clean error instead of a raw response. Access control now uses the built-in WHMCS Access Control list, and existing role lists are migrated automatically. The dashboard has been redesigned with total, monthly and daily reset counters, a quick action bar, a 7 / 30 / 90 day or all-time filter, and a new Reset Trend chart. Endpoints are now root-relative so they work from WHMCS 9 pretty admin URLs, and security was hardened across all endpoints and files. You can now choose which character types the password generator uses (letters, numbers and symbols), and passwords are generated with a cryptographically secure random source. This release also fixes the Generate button and the CSRF token on the save form, so new passwords save correctly. Features Change a password Change a password from the client profile tab Change a password from the client profile → Users tab Change a password from Clients → Manage Users One click to change a password in a native WHMCS modal Send an email notification to the user with the new password Works with WHMCS 9 pretty URLs Password generator Configurable password length (8–64) Configurable character types: letters, numbers, symbols At least one character of every selected type Cryptographically secure random generation Copy and Insert buttons Admin and audit Dashboard with total, monthly and daily reset counters Reset Trend chart with 7 / 30 / 90 day and all-time filters Activity log with actor, IP and browser user-agent Settings history that names every changed value Configurable log retention with automatic cleanup Security and access Role-based access control using the WHMCS Access Control list POST-only, CSRF-protected endpoints No passwords stored in the activity log or the email log No changes to WHMCS core files Email Ready-made Change User Password email template Changelog v2.4.1 Added: Three dashboard KPI cards: Total Resets, This Month and Today's Resets Added: Quick action bar: generate a test password, find a client, settings Added: 7 / 30 / 90 day and all-time activity filter Added: Reset Trend chart, capped at 366 days for All Time, with Chart.js 4.4.1 bundled (no CDN) Added: Password Characters setting: choose letters, numbers and symbols Added: Every selected character type is guaranteed in each generated password Added: Dashboard, Activity Log (DataTables) and admin header navigation Added: Audit log with IP and browser Added: Per-change settings history Added: AJAX settings with toast messages Updated: Modal body (a=index) is now POST-only with a CSRF token, like WHMCS core routes Updated: Opening an endpoint URL directly in the browser returns the WHMCS HTTP Method Not Allowed page Updated: Access Control now uses the built-in WHMCS role list, and the module's own role field was removed Updated: Existing role lists are migrated automatically, and an empty role list denies access, matching WHMCS Updated: Dashboard redesigned, with the activity feed sorted by date, capped at 10 rows and showing actor badges Updated: Endpoints are root-relative, so they work from WHMCS 9 pretty admin URLs Updated: Password generation is now cryptographically secure (random_int() + Fisher-Yates) instead of str_shuffle() Updated: Modern rewrite on the HSCode architecture: namespaced controllers and Smarty admin templates Fixed: Direct GET to a=store and a=password now returns the WHMCS 405 page instead of a bare JSON error Fixed: GET responses no longer mint or echo a CSRF token Fixed: Dashboard counters now count password changes only, so settings saves no longer inflate them Fixed: Generate button now works Fixed: CSRF token on the save form, so new passwords save correctly Fixed: Generator modal no longer reuses WHMCS element IDs Fixed: Length warning and pre-filled password Improved: CSRF validation is centralised in one fail-closed helper that returns a clean JSON 403 to the modal Improved: a=store and a=password use the same CSRF helper Improved: Access is enforced consistently in the UI and the endpoints Improved: Security hardening: POST-only password generation, password saves and settings saves, restricted controller dispatch, password length and NUL byte checks, direct file access blocked, .htaccess rules, and generic activation and deactivation errors