nmdpa3

Just saw that as well. Thanks!

Are they planning on rolling this out in an update? Baffling, they have not yet done so!!

If you’re going to market a platform as a professional billing system, then act like one. That means involving certified accountants, validating against real-world accounting standards, and subjecting every financial change to rigorous testing before it ever reaches production. Anything less isn’t just an oversight — it’s negligence. Rolling out changes with this level of impact, only to expose fundamental bugs, is completely unacceptable. Billing systems are not feature playgrounds. They are the financial backbone of businesses that rely on accuracy, stability, and trust. What’s most concerning is not just the presence of these issues — it’s that they made it through your release process at all. That speaks to a breakdown in quality control, testing discipline, and respect for your user base. We’ve deliberately held off upgrading to 9.x while waiting for critical modules to catch up. Based on what we’re seeing now, that decision looks more justified than ever — and we’ll be waiting considerably longer. If you want to be taken seriously in this space, raise the bar. Because right now, this isn’t it.

Two things to quickly point out: - After the upgrade to 8.12.0 there was a .github directory in the root directory which I'm guessing should not have been there - The upgrade from 8.12.0 to 8.12.1 completed, however, it errored with the message database already up to date and failed, and did not remove the install directory. However the astray .github directory went away.

If you did want to run it on a Windows server, you could install Plesk on a Windows box, then install WHMCS.

Seriously WHMCS, fix this issue. There is no reason "edit my site with SiteJet" should be shown to a customer when they are not using "SiteJet", or when no options to use SiteJet have been specified in WHMCS. It's stupid and an intrusion into our customer relationships, not to mention a problem that someone could mistakenly overlay their non-sitejet site with this option displayed. Customers using WordPress are NOT going to switch to SiteJet because this is in their face!!!! All it does is cause confusion. F'n Fix it! DUMB, DUMB, DUMB, DUMB

This issue is related to WHMCS integrating SiteJet into WHMCS, and specifically occurs when SiteJet is NOT enabled in WHMCS, but already installed and available for use independently on Plesk servers connected to WHMCS. The problem is, from the main WHMCS customer control panel, from the service that connects to a Plesk server, there will be an option in the main service page in WHMCS to edit the website with SiteJet. This occurs for every single service page connected to a Plesk server, regardless of whether the customer is using SiteJet in Plesk or not. This then allows the customer to click on the "edit with SiteJet" link, and it will launch SiteJet and if used, overlay the existing website in Plesk for that service. We have opened a ticket for this, and were pretty much told to modify smarty templates to hide this option. That is a BS reply, we're not going to do mods on templates to hide WHMCS errors. What does it take to get this fixed before someone trashes a valid website when clicking on the edit in SiteJet link to see what it does?

A little off topic but an area for improvement.....we do not allow any order from a new customer to process automatically, and require it be reviewed first by humans. That said, the WHMCS process of how those orders are held is flawed. WHMCS will process the payment first then hold the order, regardless of the fact that we want the order held for human review (BEFORE payment is processed). We have bemoaned this for years and have always been told "that's just the way it is when using payment gateways". I never understood this response, as it should be easy to take an order, HOLD the order BEFORE payment processing, allow a human review, and then allow the operator to release the order for payment processing AFTER the review.

So, WHMCS doesn't know or doesn't want to comment at this point, or does not reply in their community forums? We're also opening a ticket with same request. Plesk is currently at 18.0.61 Update #4, so 18.0.62 has to be right around the corner. This is critical to know.

Will this be an issue with WHMCS Plesk modules? For anyone who's using the Plesk REST API, please note that starting from Plesk Obsidian 18.0.62, requests to REST API containing the Content-Type header with a media-type directive other than “application/json” will result in the HTTP “415 Unsupported Media Type” client error response code. Since the curl commands send the “Content-Type: application/x-www-form-urlencoded” header by default, you need to add the --header "Content-Type: application/json" option to such commands to keep them working correctly. We strongly recommend that you check your existing integrations that use cURL for compliance with this change and update them if necessary. Failure to do so may result in any such integrations ceasing to work after updating to Plesk Obsidian 18.0.62.

Additionally, this error could be caused because your database does not have the "drop" privilege. For whatever reason it appears the compatibility check requires the drop privilege.

Thanks for your input. Not really interested in a 3rd party database reporting tool or directly reporting from the database outside of WHMCS. The question was directed toward WHMCS's plans regarding the existing capability.

Are there any updates on the books that will add the ability to show search result totals from Billing - > Invoices - > Search Filter? You can currently search for invoices by criteria here, but the results show no caclulated totals for the line items displayed by the search result, and provide no way to export the results to a csv, xls, etc.

MODULE-6758 - Correct "Login to Plesk Control Panel" client area action Would this be to address the "quick shortcut" links that don't properly link to the proper plesk pages from the WHMCS client area?

For Plesk shortcuts introduced from the client view in 8.3, is there: a) an option to remove these (if not, one would be nice so no customizations need to be made) b) a way to set where the shortcut links resolve to. Right now they resolve to a default account overview page in plesk.

Not really seeing an issue which is puzzling. Cron is running every 5 minutes. This was not a problem prior to the upgrade. As a side note, this is the 2nd API issue we've seen with Plesk. A fix was provided to us this past weekend to correct the first, which was related to Plesk module not provisioning new accounts due to API call issues introduced with the upgrade. This stats update issue is not a critical issue for us at the moment, since refreshing the stats manually with the refresh button works, but something is definitely different after the upgrade to 8.2 -- since it was working prior to that and nothing else was changed. If I get a chance, I will enable debuging, but not a path I prefer to take on a production system.

After upgrade to 8.2.0, the remote useage stats and load averages on the servers page is defaulting to the values of the first server in the list for every server. If you refresh them individualy, or with the refresh all button, it gets updated to the correct value, however leaving then returning to the page results in the same behavior.

Version 8.0.4, If you try to create a client from the admin side, and it takes some sort of error ---ala some weird icaan message about client must have a valid reachable email (yes this happens)....WHMCS creates a stranded user, not associated with any client, and it can not be deleted. This is a different reason we should be able to delete a user from Manage Users. If the logic in not allowing this based upon a user accidentally being deleted that should not be (aka an active user associated with a client) then add code to run a check on the database and kick a message saying it can't be deleted because its used.....otherwise, we need a way to delete users from Manage Users,

Experiencing same. Thanks for posting.