bear

If that's the one that came with WHMCS, I believe that file does nothing in versions past 7.5. It's there as a placeholder only, and has no functions in it.

Your file is name .custom.css, with the leading ".", or is that a typo?

This is a few years old, but there's a request under consideration: https://requests.whmcs.com/topic/support-ticket-custom-field-type-for-encrypted-data

Here's a thread from a while back, in which Sparky had created/shared a script with me that was working in v5. It would likely need updating to work in the new WHMCS versions. The code wasn't shared there, but I have a copy of it here, I believe. Since it was mostly his work/effort, I can't share it unless he says it's ok, or maybe he'd still have that and be willing himself.

Least I could do, no worries. :) Best thing once that's working for you is to visit as a customer and see any other references that might need fixing. There are ticket count blocks in the main client page and so on.

We do the same on one of our installs, and it's a matter of edits to the menu system via hooks, mostly. When setting it up, we loaded the pages as they are now and looked for all references to these, and worked our way through the templates to see where they were referenced. Don't forget the email templates, since some have a footer with a helpdesk link in them. Here's the KB one we use (change the obvious in the URL part): <?php use WHMCS\View\Menu\Item as MenuItem; add_hook('ClientAreaPrimaryNavbar', 1, function (MenuItem $primaryNavbar) { $newURL = 'https://mydomain.com/desk/index.php?/Knowledgebase/List'; if (!is_null($primaryNavbar->getChild('Knowledgebase'))) { $primaryNavbar->getChild('Knowledgebase') ->setURI($newURL); } if (!is_null($primaryNavbar->getChild('Support'))) { $primaryNavbar->getChild('Support') ->getChild('Knowledgebase') ->setURI($newURL); } }); add_hook('ClientAreaSecondarySidebar', 1, function (MenuItem $secondarySidebar) { $newURL = 'https://mydomain.com/desk/index.php?/Knowledgebase/List'; if (!is_null($secondarySidebar->getChild('Support'))) { $secondarySidebar->getChild('Support') ->getChild('Knowledgebase') ->setURI($newURL); } }); We also created a Kayako database user with read only perms, and wrote a widget that will call that db and show ticket counts within the WHMCS admin dashboard. Didn't do that for customers, though.

Check with your provider to see if they have a backup that has it. If not, that's that. You need to start over with the installation. As soon as you're done, start a regular backup regimen, and keep offsite copies. :)

I'm having this exact same issue, except the PHP version is 7.0. This is on a multi-php server, and the default is php 5.6, and this site was changed to php 7.0. As soon as that was done, the daily task fails via cron, though all other tasks work and running the cron via CLI completes without error. It worked fine on 5.6. The cron does appear to be calling the 5.6 php.ini file, but since it worked then, that shouldn't make any difference. I think. Puzzling. Ticket in.

Following the information on this page: https://docs.whmcs.com/Version_7.0-7.4_System_Requirements Ioncube Loaders The latest 6.x version for PHP 7 Added the 6.x version via EA4 (PHP7.0), and the files wouldn't run, with the normal "index.php is corrupted" error. Chose to install the 10.x version of ioncube and it worked without issue. Maybe that needs updating?

The most recent version of WHMCS, release date late August, still includes two files that don't allow the normal domain sync to run via cron. There was a patch released that contained a prior version that fixed it. Looking at the most recent download, it still has the incorrect file(s) in it. Just wondering why that's not been fixed and stuck into the download at some point? \vendor\whmcs\whmcs-foundation\lib\Cron\Task\DomainExpirySync.php \vendor\whmcs\whmcs-foundation\lib\Cron\Task\DomainTransferSync.php Newly updated site, the cron wasn't doing the domain sync (would if manually run via CLI) until I replaced those in the download, just as before. Surely others have been seeing this issue also?

Looks like this setting under automation may stop the attempts: "Attempt Only Once Tick this box to only attempt the payment automatically once and if it fails, don't attempt it again" But that raises a question as to why it only allows you to make one attempt, and no way to try a second time without it doing so repeatedly without end, assuming this was causing it. Reading more carefully, the docs explain the somewhat ambiguous wording in the admin interface, and setting the "Enter the number of weeks to retry failed CC processing attempts for weekly" is not for weekly hosting periods, but how many weeks it should make the attempt. IMHO, that "for weekly" bit should be removed. Problem solved.

I have a client that's sometimes late paying, but it's a known thing and we've discussed it with them. Recently he's had an invoice for a credit card payment (none on file) go overdue, and it generated the usual 1/2/3 reminders. As of a few days ago, however, it's sending payment reminders every single day since it's past the 3rd reminder and he's still not handled it. I feel that's excessive, but can't find where that can be adjusted or stopped. Aside from changing the payment method on the account, can this be adjusted at all?

That path will be wrong unless the "external" file is in or a sub of WHMCS' directory. It needs the path to the file, which if it's being called from *outside* of the WHMCS directory would be more like "require('whmcs/getuserid.php');" if on the same level as WHMCS' directory, but not in it.

I know you understand, I was referring to slim's post (and why I'd quoted it). 😉 I agree there could and should be a setting to choose, but it's like so many things in this system (hard coded UK dates on domain sync, for instance), it gets encoded and untouchable or needs yet another hook.

That's on the client running the site, not the WHMCS admin clicking a link to go there from within WHMCS. As for that link being http or https, not all sites have gone secured, so it's a toss up as to which will be correct in all cases. Hard to predict which it will be...