splaquet

I found myself having this issue as well. This post most accurately expressed the issue, but didn’t appear to have a resolution. Somehow I had also missed that my CLIENT email templates weren’t displaying in the dashboard. I was seeing them in the database, but they weren’t displaying in the dashboard After searching and searching for an answer, looking through my template files, database, debugging, etc… I finally installed a dev build to compare to. The only difference I found was that my old/existing database had NULL in the empty reset password fields. Oddly enough, when I replaced the NULL entries with empty content, the reset password URLs magically reappeared in the reset password emails. As well, the CLIENT email template reappeared in the email template section of the dashboard. I’m not sure if I feel like a genius or a moron, because this solution doesn’t make sense to me.

I can confirm that this worked for me.

ahhhh... so happy to see that i'm not the only one having/noticing this issue. a client of mine brought it to my attention last week. i had searched online for others having the same problem, but stumbled upon this old thread. i'm happy to see that thread has new life and that i'm not the only one having this issue!

soooo... are you saying that it's never worked correctly, and was recently updated and fixed? i might be mistaken, but i assumed that the BED feature was to prefect people from purchasing/registering domains that were already in use. out of curiousity, do you have BED enabled or disabled? and if it's enabled, how do your customers purchase hosting packages, if their domains have already been purchased (elsewhere or locally)?

I went in to add GSuite to one of my client's accounts, just the same way as I've always done it. The only difference since the last one is the upgrade to the latest WHMCS version. I unchecked "Block Existing Domains" in General Settings > Ordering ... & saved That allowed me to place the order... but, I'm pretty sure this is a glitch in the latest software.

Oh man... thank gawd that others had this issue. I was starting to freak, as the pile of client tickets of “I cannot pay my invoice!” was adding up. Disabling the pdo_mysql PHP extension and activating nd_pdo_mysql worked. I mean... if your clients see that you can’t make one of the most important functions of a billing solution work for your own company, how/why would they want to trust you with their own livelihoods?! Yo WHMCS folks... think you can have an alert flag us during an upgrade, alerting us that we have an incompatible php extension activated?

I've been seeing a few processing issues with reporting statuses, on: Client > Invoices > Invoice # I finally had to double check and compare my local/stipe.com previous 4 weeks data... because it'd be horrible if these statuses were correct! here's a few examples of what I've been seeing, on the Transaction History section (bottom of paid invoices). and these are *all* reporting as being *PAID*. i haven't looked through everything in detail, but they (so far) appear to all be paid. looks as though the status & descriptions simply aren't matching up in our admin area. (at least, i hope that's all that it is) Date Payment Method Transaction ID Status Description 02/19/2020 15:04 Credit Card N/A Success Your card has insufficient funds. 02/19/2020 15:04 Credit Card txn_notrealtrxnumber Success Your card has insufficient funds. 02/19/2020 15:04 Credit Card txn_notrealtrxnumber Success Automatic Payment Attempt

I realize all that, but I do thank you for the reply. It's mostly that it seems counter intuitive for WHMCS to leave such simple functionality from their core. In theory... WHMCS users would sell more services, to potentially new customers, raising the value of the WHMCS software to current users. A third-party sitemap generator is simple enough to initially create... but something is going to suffer, when we're having to regenerate and upload new sitemaps for every new product/service/promotion/etc. Simple enough, my time. My time spent on such a simple task (when automated) leaves me feeling a bit taken advantage of, considering the thousands of dollars that I've spent on WHMCS over the years.

maybe it's just me, but has anyone else been a bit confused by the fact that the whmcs system does not appear to have native sitemap functionality? anyone have an easy workaround or alternate solution they'd like to share?

...not sure why i hadn't looked into the server's apache error log before, but i just did... looks like i need to figure out how and why oauth.so stopped loading randomly. wow... how strange [Thu Jun 06 18:02:50.297961 2019] [lsapi:notice] [pid 129818:tid 47378050160384] [client 71.235.43.210:47675] [host REMOVED.com] Backend log: [WHMCS Application] ERROR: Whoops\\Exception\\ErrorException: PHP Startup: Unable to load dynamic library 'oauth.so' (tried: /opt/alt/php72/usr/lib64/php/modules/oauth.so (/opt/alt/php72/usr/lib64/php/modules/oauth.so: undefined symbol: core_globals_id), /opt/alt/php72/usr/lib64/php/modules/oauth.so.so (/opt/alt/php72/usr/lib64/php/modules/oauth.so.so: cannot open shared object file: No such file or directory)) in Unknown:0 Stack trace: #0 /REMOVED/vendor/whmcs/whmcs-foundation/lib/Utility/Error/Run.php(0): WHMCS\\Utility\\Error\\Run->handleError(32, 'PHP Startup: Un...', 'Unknown', 0) #1 [internal function]: WHMCS\\Utility\\Error\\Run->handleShutdown() #2 {main} {"exception":"[object] (Whoops\\\\Exception\\\\ErrorException(code: 32): PHP Startup: Unable to load dynamic library 'oauth.so' (tried: /opt/alt/php72/usr/lib64/php/modules/oauth.so (/opt/alt/php72/usr/lib64/php/modules/oauth.so: undefined symbol: core_globals_id), /opt/alt/php72/usr/lib64/php/modules/oauth.so.so (/opt/alt/php72/usr/lib64/php/modules/oauth.so.so: cannot open shared object file: No such file or directory)) at Unknown:0)"} []\n [Thu Jun 06 18:28:49.269577 2019] [lsapi:notice] [pid 161114:tid 47378172315392] [client 71.235.43.210:48113] [host REMOVED.com] Backend log: [WHMCS Application] ERROR: Whoops\\Exception\\ErrorException: PHP Startup: Unable to load dynamic library 'ssh2.so' (tried: /opt/alt/php72/usr/lib64/php/modules/ssh2.so (/opt/alt/php72/usr/lib64/php/modules/ssh2.so: undefined symbol: file_globals_id), /opt/alt/php72/usr/lib64/php/modules/ssh2.so.so (/opt/alt/php72/usr/lib64/php/modules/ssh2.so.so: cannot open shared object file: No such file or directory)) in Unknown:0 Stack trace: #0 /REMOVED/vendor/whmcs/whmcs-foundation/lib/Utility/Error/Run.php(0): WHMCS\\Utility\\Error\\Run->handleError(32, 'PHP Startup: Un...', 'Unknown', 0) #1 [internal function]: WHMCS\\Utility\\Error\\Run->handleShutdown() #2 {main} {"exception":"[object] (Whoops\\\\Exception\\\\ErrorException(code: 32): PHP Startup: Unable to load dynamic library 'ssh2.so' (tried: /opt/alt/php72/usr/lib64/php/modules/ssh2.so (/opt/alt/php72/usr/lib64/php/modules/ssh2.so: undefined symbol: file_globals_id), /opt/alt/php72/usr/lib64/php/modules/ssh2.so.so (/opt/alt/php72/usr/lib64/php/modules/ssh2.so.so: cannot open shared object file: No such file or directory)) at Unknown:0)"} []\n

Unless my knowledge base tables are corrupted, I don't think that's my issue. I cannot access anything on my WHMCS install. Those error lines are the only ones in my error log though. Nothing else seems to be throwing any flags. The odd part for me was that I had literally logged in, totally fine. A client called, so I logged into the admin area. We talked for a few minutes... then I entered his name into the search bar. Nothing resulted, similar to when your login session has expired. I refreshed the page and it still showed me as logged in, so I tried the search again. Same result, so I clicked on logout... and then the WHMCS error page loaded up. Really odd, and no indication of what caused it. I tried uploading a fresh vendors folder (as I found that suggestion elsewhere on here), but still nothing. I'm uploading a completely fresh file set now, so hopefully that'll do it. ### And, although I hadn't made any server changes... I did notice that my CloudLinux > PHP Selector modules had been updated over night. On most of the mods in 7.2, there's a second listing. The new ones end in "xxx-zts"

this same error just popped up for me today... apparently out of nowhere?! i was using it okay just yesterday, and haven't made any server updates/tweaks/changes.

@WHMCS John... i just resolved it!!! just now actually 😮 🤘🏻 i also just noticed that my last successful full cron, including DB backup -> remote ftp upload, hadn't completed since 2017-7-1 here's my original posting on the topic. i went to reply back to that post with this entire reply, but the post was closed. ...so, i'll post it here 😄 so unfortunately, if you read through that thread, you'll see that i never 100% completed the support ticket. not sure if the ticket support system has changed, but it'd be super awesome if we could create WHMCS profiles. that way, filling in all of that extra info wouldn't be necessary to submit a single ticket. anyhow... it has been so long, i really don't recall what it was that exactly tipped me off, that something in WHMCS wasn't properly executing. there was something that was different though... something wasn't working correctly, but the core functionality was. nothing threw me off my game enough to stop everything and focus on the issue, until now. after reading through several threads on forums.cpanel & whmcs.community, i finally put enough pieces together to resolve the issue. if i had to make an educated guess, it'd be that whmcs was having some serious issues with those large logs. i'm not sure if it was a corrupt chunk, incorrect charset/collation, or something else, but it stopped. so, piecing things together, i noticed that several folks were having issues with the size of the following two tables... as was I. tbladminlog was nearly 200mb tblactivitylog was nearly 12gb!?!?! as most folks reporting an issue, my force cron command kept getting stuck. I was having an odd issue with WHMCS yesterday, so I went to force run the cron again. I saw a slightly different message this time. i knew what the issue was (CloudLinux PHP mod that was unchecked), so i fixed it... but mine was still getting stuck at the last step (as it was before): $ /usr/local/bin/php -q /home/domain/public_html/management/crons/cron.php all -F -vvv WHMCS Automation Task Utility: all ================================== Daily Cron Automation Mode Queuing Tasks ------------- Force run any tasks: ignore "in progress" and "is due" Task queues ready Executing Application Queue --------------------------- 0/27 [░░░░░░░░░░░░░░░░░░░░░░░░░░░░] 0% < 1 sec/< 1 sec 24.0 MiB Currency Exchange Rates 1/27 [▓░░░░░░░░░░░░░░░░░░░░░░░░░░░] 3% 1 sec/27 secs 24.0 MiB Product Pricing Updates 2/27 [▓▓░░░░░░░░░░░░░░░░░░░░░░░░░░] 7% 1 sec/14 secs 24.0 MiB Invoices 3/27 [▓▓▓░░░░░░░░░░░░░░░░░░░░░░░░░] 11% 1 sec/9 secs 24.0 MiB Late Fees 4/27 [▓▓▓▓░░░░░░░░░░░░░░░░░░░░░░░░] 14% 2 secs/14 secs 24.0 MiB Credit Card Charges 5/27 [▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░░░░] 18% 7 secs/38 secs 40.0 MiB Invoice & Overdue Reminders 6/27 [▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░░░] 22% 9 secs/41 secs 40.0 MiB Domain Renewal Notices 7/27 [▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░░] 25% 9 secs/35 secs 40.0 MiB Cancellation Requests 8/27 [▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░] 29% 9 secs/30 secs 44.0 MiB Overdue Suspensions 9/27 [▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░] 33% 10 secs/30 secs 40.0 MiB Overdue Terminations 10/27 [▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░] 37% 10 secs/27 secs 40.0 MiB Fixed Term Terminations 11/27 [▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░] 40% 10 secs/25 secs 40.0 MiB Inactive Tickets 12/27 [▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░] 44% 10 secs/23 secs 40.0 MiB Delayed Affiliate Commissions 13/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░] 48% 10 secs/21 secs 40.0 MiB Affiliate Reports 14/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░] 51% 10 secs/19 secs 40.0 MiB Email Marketer Rules 15/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░] 55% 11 secs/20 secs 42.0 MiB Credit Card Expiry Notices 16/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░] 59% 11 secs/19 secs 40.0 MiB SSL Sync [ERROR] PDOException: SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '=' in /home/domain/public_html/management/vendor/illuminate/database/Connection.php:335 Stack trace: #0 /home/domain/public_html/management/vendor/illuminate/database/Connection.php(335): PDOStatement->execute(Array) #1 /home/domain/public_html/management/vendor/illuminate/database/Connection.php(706): Illuminate\Database\Connection->Illuminate\Database\{closure}(Object(Illuminate\Database\MySqlConnection), 'select `userid`...', Array) #2 /home/domain/public_html/management/vendor/illuminate/database/Connection.php(669): Illuminate\Database\Connection->runQueryCallback('select `userid`...', Array, Object(Closure)) #3 /home/domain/public_html/management/vendor/illuminate/database/Connection.php(342): Illuminate\Database\Connection->run('select `userid`...', Array, Object(Closure)) #4 /home/domain/public_html/management/vendor/illuminate/database/Query/Builder.php(1583): Illuminate\Database\Connection->select('select `userid`...', Array, true) #5 /home/domain/public_html/management/vendor/illuminate/database/Query/Builder.php(1569): Illuminate\Database\Query\Builder->runSelect() #6 /home/domain/public_html/management/vendor/illuminate/database/Query/Builder.php(1813): Illuminate\Database\Query\Builder->get(Array) #7 /home/domain/public_html/management/vendor/illuminate/database/Eloquent/Builder.php(442): Illuminate\Database\Query\Builder->pluck('userid', 'domain') #8 /home/domain/public_html/management/vendor/whmcs/whmcs-foundation/lib/Cron/Task/SslStatusSync.php(0): Illuminate\Database\Eloquent\Builder->pluck('userid', 'domain') #9 /home/domain/public_html/management/vendor/whmcs/whmcs-foundation/lib/Cron/Task/SslStatusSync.php(0): WHMCS\Cron\Task\SslStatusSync->getNewDomains() #10 /home/domain/public_html/management/vendor/whmcs/whmcs-foundation/lib/Scheduling/Task/AbstractTask.php(0): WHMCS\Cron\Task\SslStatusSync->__invoke() #11 /home/domain/public_html/management/vendor/whmcs/whmcs-foundation/lib/Scheduling/Task/AbstractTask.php(0): WHMCS\Scheduling\Task\AbstractTask->execute() #12 /home/domain/public_html/management/vendor/whmcs/whmcs-foundation/lib/Cron/Console/Command/AbstractCronComma nd.php(0): WHMCS\Scheduling\Task\AbstractTask->run() #13 /home/domain/public_html/management/vendor/whmcs/whmcs-foundation/lib/Cron/Console/Command/AbstractCronComma nd.php(0): WHMCS\Cron\Console\Command\AbstractCronCommand->executeCollection(Object(WHMCS\Scheduling\Task\Collection)) #14 /home/domain/public_html/management/vendor/symfony/console/Command/Command.php(259): WHMCS\Cron\Console\Command\AbstractCronCommand->execute(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #15 /home/domain/public_html/management/vendor/symfony/console/Application.php(844): Symfony\Component\Console\Command\Command->run(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #16 /home/domain/public_html/management/vendor/symfony/console/Application.php(192): Symfony\Component\Console\Application->doRunCommand(Object(WHMCS\Cron\Console\Command\AllCommand), Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #17 /home/domain/public_html/management/vendor/symfony/console/Application.php(123): Symfony\Component\Console\Application->doRun(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #18 /home/domain/public_html/management/crons/cron.php(0): Symfony\Component\Console\Application->run(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #19 {main} Next Illuminate\Database\QueryException: SQLSTATE[HY000]: General error: 1267 Illegal mix of collations (utf8_general_ci,IMPLICIT) and (utf8_unicode_ci,IMPLICIT) for operation '=' (SQL: select `userid`, `domain` from `tblhosting` where `domain` != and domain NOT IN (SELECT domain_name FROM tblsslstatus)) in /home/domain/public_html/management/vendor/illuminate/database/Connection.php:713 Stack trace: #0 /home/domain/public_html/management/vendor/illuminate/database/Connection.php(669): Illuminate\Database\Connection->runQueryCallback('select `userid`...', Array, Object(Closure)) #1 /home/domain/public_html/management/vendor/illuminate/database/Connection.php(342): Illuminate\Database\Connection->run('select `userid`...', Array, Object(Closure)) #2 /home/domain/public_html/management/vendor/illuminate/database/Query/Builder.php(1583): Illuminate\Database\Connection->select('select `userid`...', Array, true) #3 /home/domain/public_html/management/vendor/illuminate/database/Query/Builder.php(1569): Illuminate\Database\Query\Builder->runSelect() #4 /home/domain/public_html/management/vendor/illuminate/database/Query/Builder.php(1813): Illuminate\Database\Query\Builder->get(Array) #5 /home/domain/public_html/management/vendor/illuminate/database/Eloquent/Builder.php(442): Illuminate\Database\Query\Builder->pluck('userid', 'domain') #6 /home/domain/public_html/management/vendor/whmcs/whmcs-foundation/lib/Cron/Task/SslStatusSync.php(0): Illuminate\Database\Eloquent\Builder->pluck('userid', 'domain') #7 /home/domain/public_html/management/vendor/whmcs/whmcs-foundation/lib/Cron/Task/SslStatusSync.php(0): WHMCS\Cron\Task\SslStatusSync->getNewDomains() #8 /home/domain/public_html/management/vendor/whmcs/whmcs-foundation/lib/Scheduling/Task/AbstractTask.php(0): WHMCS\Cron\Task\SslStatusSync->__invoke() #9 /home/domain/public_html/management/vendor/whmcs/whmcs-foundation/lib/Scheduling/Task/AbstractTask.php(0): WHMCS\Scheduling\Task\AbstractTask->execute() #10 /home/domain/public_html/management/vendor/whmcs/whmcs-foundation/lib/Cron/Console/Command/AbstractCronComma nd.php(0): WHMCS\Scheduling\Task\AbstractTask->run() #11 /home/domain/public_html/management/vendor/whmcs/whmcs-foundation/lib/Cron/Console/Command/AbstractCronComma nd.php(0): WHMCS\Cron\Console\Command\AbstractCronCommand->executeCollection(Object(WHMCS\Scheduling\Task\Collection)) #12 /home/domain/public_html/management/vendor/symfony/console/Command/Command.php(259): WHMCS\Cron\Console\Command\AbstractCronCommand->execute(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #13 /home/domain/public_html/management/vendor/symfony/console/Application.php(844): Symfony\Component\Console\Command\Command->run(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #14 /home/domain/public_html/management/vendor/symfony/console/Application.php(192): Symfony\Component\Console\Application->doRunCommand(Object(WHMCS\Cron\Console\Command\AllCommand), Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #15 /home/domain/public_html/management/vendor/symfony/console/Application.php(123): Symfony\Component\Console\Application->doRun(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #16 /home/domain/public_html/management/crons/cron.php(0): Symfony\Component\Console\Application->run(Object(WHMCS\Cron\Console\Input\CliInput), Object(Symfony\Component\Console\Output\ConsoleOutput)) #17 {main} 17/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░] 62% 11 secs/17 secs 40.0 MiB Server Usage Stats 18/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░] 66% 20 secs/30 secs 48.0 MiB Overage Billing Charges 19/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░] 70% 20 secs/28 secs 48.0 MiB Client Status Update 20/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░] 74% 20 secs/27 secs 48.0 MiB Domain Expiry 21/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░] 77% 20 secs/26 secs 48.0 MiB Ticket Escalation Rules 22/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░] 81% 20 secs/25 secs 48.0 MiB Data Retention Pruning 23/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░] 85% 21 secs/25 secs 48.0 MiB WHMCS Updates 24/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░] 88% 23 secs/26 secs 54.2 MiB Run Jobs Queue 25/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░] 92% 23 secs/25 secs 54.2 MiB Domain Transfer Status Synchronisation 26/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░] 96% 24 secs/25 secs 54.2 MiB Domain Expiry Synchronisation 27/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100% 25 secs/25 secs 54.2 MiB Sending Daily Cron Digest email Executing System Queue ---------------------- 3/4 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░] 75% 2 secs/3 secs 56.2 MiBHangup EVERY FREAKIN' TIME!!! ### so... jump ahead to yesterday (approx 1.5 years later) i found a thread on cpanel forums that had someone perform that force cron with ptrace. so: $ strace /bin/php -q /home/oogleplop/public_html/management/crons/cron.php all -F -vvv I noticed that it kept repeating these following lines, but not moving past them: write(8, "INSERT INTO `tbladminlog` (`id`,"..., 261) = 261 write(8, "INSERT INTO `tbladminlog` (`id`,"..., 262) = 262 write(8, "INSERT INTO `tbladminlog` (`id`,"..., 263) = 263 write(8, "INSERT INTO `tbladminlog` (`id`,"..., 264) = 264 write(8, "INSERT INTO `tbladminlog` (`id`,"..., 265) = 265 write(8, "INSERT INTO `tbladminlog` (`id`,"..., 266) = 266 write(8, "INSERT INTO `tbladminlog` (`id`,"..., 267) = 267 write(8, "INSERT INTO `tbladminlog` (`id`,"..., 268) = 268 write(8, "INSERT INTO `tbladminlog` (`id`,"..., 269) = 269 write(8, "INSERT INTO `tbladminlog` (`id`,"..., 270) = 270 I finally just went into those two tables (tbladminlog & tblactivitylog) and deleted all of the records from 2015%, 2016%, 2017% & 2018-0% tbladminlog is now 9mb tblactivitylog is now 63mb as silly as it sounds... it finally, freakin', worked! (as seen below) IMO... WHMCS needs to create a solution to these ridiculously oversized and out of control logs. i had my limit set to 10000 rows in general settings, and i've purged my logs several times. but, from reading the forums and what others have said, it sounds as though these logs aren't touched by purging them. $ /usr/local/bin/php -q /home/domain/public_html/management/crons/cron.php all -F -vvv WHMCS Automation Task Utility: all ================================== Daily Cron Automation Mode Queuing Tasks ------------- Force run any tasks: ignore "in progress" and "is due" Task queues ready Executing Application Queue --------------------------- 0/27 [░░░░░░░░░░░░░░░░░░░░░░░░░░░░] 0% < 1 sec/< 1 sec 24.0 MiB Currency Exchange Rates 1/27 [▓░░░░░░░░░░░░░░░░░░░░░░░░░░░] 3% 1 sec/27 secs 24.0 MiB Product Pricing Updates 2/27 [▓▓░░░░░░░░░░░░░░░░░░░░░░░░░░] 7% 1 sec/14 secs 24.0 MiB Invoices 3/27 [▓▓▓░░░░░░░░░░░░░░░░░░░░░░░░░] 11% 2 secs/18 secs 24.0 MiB Late Fees 4/27 [▓▓▓▓░░░░░░░░░░░░░░░░░░░░░░░░] 14% 2 secs/14 secs 24.0 MiB Credit Card Charges 5/27 [▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░░░░] 18% 7 secs/38 secs 40.0 MiB Invoice & Overdue Reminders 6/27 [▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░░░] 22% 10 secs/45 secs 40.0 MiB Domain Renewal Notices 7/27 [▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░░] 25% 10 secs/39 secs 40.0 MiB Cancellation Requests 8/27 [▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░░] 29% 11 secs/37 secs 42.0 MiB Overdue Suspensions 9/27 [▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░░] 33% 11 secs/33 secs 42.0 MiB Overdue Terminations 10/27 [▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░░] 37% 12 secs/32 secs 42.0 MiB Fixed Term Terminations 11/27 [▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░░] 40% 12 secs/29 secs 42.0 MiB Inactive Tickets 12/27 [▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░░] 44% 12 secs/27 secs 42.0 MiB Delayed Affiliate Commissions 13/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░░] 48% 13 secs/27 secs 42.0 MiB Affiliate Reports 14/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░░] 51% 26 secs/50 secs 42.0 MiB Email Marketer Rules 15/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░░] 55% 26 secs/47 secs 42.0 MiB Credit Card Expiry Notices 16/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░░] 59% 27 secs/46 secs 42.0 MiB SSL Sync 17/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░░] 62% 3 mins/5 mins 42.0 MiB Server Usage Stats 18/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░░] 66% 3 mins/5 mins 48.0 MiB Overage Billing Charges 19/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░░] 70% 3 mins/4 mins 48.0 MiB Client Status Update 20/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░░] 74% 3 mins/4 mins 48.0 MiB Domain Expiry 21/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░] 77% 3 mins/4 mins 48.0 MiB Ticket Escalation Rules 22/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░] 81% 3 mins/4 mins 48.0 MiB Data Retention Pruning 23/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░] 85% 3 mins/3 mins 48.0 MiB WHMCS Updates 24/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░] 88% 3 mins/3 mins 54.2 MiB Run Jobs Queue 25/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░] 92% 3 mins/3 mins 54.2 MiB Domain Transfer Status Synchronisation 26/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░] 96% 3 mins/3 mins 54.2 MiB Domain Expiry Synchronisation 27/27 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100% 3 mins/3 mins 56.2 MiB Sending Daily Cron Digest email Executing System Queue ---------------------- 4/4 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓] 100% 17 mins/17 mins 62.2 MiB [OK] Completed

@brian!, my apologies for not expressing my appreciation! i've been so busy and so overworked lately... that i haven't been able to try your patch yet. i truly appreciate your efforts though, and i totally will ASAP!!! i'm still dealing with an "Executing System Queue" stuck cron issue, that's plagued me for nearly a year now. i should probably focus on fixing functionality, before tweaking my cosmetics for convenience. ...especially since WHMCS has been of no help in replying to my year old thread/issue 😕

Thank you kindly Brian! As I mentioned previously, it only seems as though this feature would be an obvious integration from the top. I realize that not many folks have clients with dozens or hundreds of services/products/domains... but, for those that do, the limitations of whmcs start appearing. Such as, having the client's primary key be set to their email! I realize that's how the "big guys" have it, but that doesn't mean that my clients can understand that. ..."you mean, I need to have seperate accounts setup for each artist, if I'm going to have each of our artists pay with their own CC and receive seperate invoices? How am I possibly thing to remember all of those logins?! ...and why do I receive so many emails from you?!" (From one of the artist managment companies that I represent) In my opinion, following the masses puts you in line to meet the "average" expectations, but exceeding those expectations is what seperates you from the pack... putting you on track to become an industry leader. So Brian, on that note, I thank you for helping lead the pack! 🙂

Yeah, those screenshots are actually *exactly* what I was looking for! Thank you so much for sharing that post. I'm not sure how/why I wasn't able to find it on my own. Would it make sense to simply integrate that into the master templates, for everyone to use? ### After submitting my reply, I went back through your post to find "the link" with more info... and hopefully the code mods to copy/paste. BUT, then after not finding a link, i realized that those must be screenshots of your own install? If that's the case, would you mind sharing? (To save this guy from having to stumble through my first smarty template mods!)

It'd be super convenient if a total was shown for the various Products/Services, Domains, and other products! I have a client with a TON of domains. Active, Expired, Transferred, etc... It'd be a real time saver, if those counts could be also be included within the appropriate section. I realize that there's a total count up top, in the Products/Services box, but some of these pages and up becoming *super* long to scroll back and forth in. just my .02 - splaquet

Does anyone have recommendations for "the best" GSuite CRM, WHMCS module or other? The marketplace seems to feature several modules that use third party reseller accounts to sell GSuite services... but I'm a GSuite Partner/reseller myself! I've purchased and installed the one from ModulesGarden ( https://marketplace.whmcs.com/product/1782 ), but it just doesn't "feel" right. I set up and manage most of my clients' user deployments, so that part is easier, but I also have clients who use GSuite Basic, Business & Enterprise. Unless I'm really missing something, and not setting it up correctly (I've followed the setup instructions about 3 times now), it just doesn't do a good job at managing the various packages. GSuite Basic is easy enough, but when you add in the additional packages to the mix, it doesn't seem to "add up". Anyhow, I'm looking for a solution. Doesn't have to be a WHMCS module, but that'd be ideal. Are there any other GSuite Partners/resellers on here? If so, can anyone else on here chime in as to what they're using?

Thank you for your input! I'm not sure if that's what my issue is, but it sounds like your familiar enough with the error. I'll have to double check on the timeout! The previous steps, up until that error, only take seconds. Why would the final 25% of the final test take so long? How long is the process supposed to take? I submitted a ticket to support, but never heard back. I believe that even though I submitted the ticket, I never submitted the "highly recommended" info on the second page. I never would have assumed that "highly suggested" would have prevented the ticket from going through ?

Anyone?

For starters, I'm on a CloudLinux system and within CageFS. I need to upgrade a few things to be php7+ compatible, but am using php5.6 for the time being. When I have my account in the Native(php5.6) version (in php selector), things run "okay"... or, at least good enough for now. When I change the account to run in the php5.6 shell, my wordpress install runs fine, but my WHMCS install changes to a 500 error in Apache. I've tried every extension combination that I can think of, but I just can't get WHMCS running in the php5.6 shell. Seems silly, as it runs okay in Native shell. The reason why I keep playing around with this is because I'm having an issue while running the nightly cron job: /crons/cron.php All of my other crons seem to run totally fine, but this one stalls out on me AND locks up my WHMCS/account install. (see below) Executing System Queue ---------------------- 3/4 [▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓▓░░░░░░░] 75% < 1 sec/< 1 sec 29.5 MiB I've tried running this cron several different ways, but it keeps stalling out in the same spot. I've double checked my server settings and anything and everything I could think of OR find referenced on WHMCS troubleshooting techniques. So... long story short, can anyone offer up any suggestions on how to resolve this?

I found two bugs, or at least what would appear to be bugs. The first one, which actually isn't this one i'm posting about, is on the Manage Orders page. I had a domain renewal come through. ...why it doesn't automatically approve is beyond me (another bug? i have automatically approve turned on)... but at any rate, I saw a renewal order come through for 2 of my client's domains. the page wouldn't let me check off "send email" and "send renewal to registrar". the boxes were greyed out and unfortunately, I didn't take a screenshot. since i couldn't click on anything, and i knew that they were expiring today/tomorrow... i just tried clicking accept order. it seemed to push the order through just fine and the domains were renewed... but that just can't be right. i then when into the domain management to verify that they had renewed. i noticed that DNS Management, Email Forwarding & ID Protection weren't checked off. the first 2 can check off and save just fine. when i try and check off & save ID Protection, I receiving the message "Enabling ID Protection may cause charges at the registrar. Are you sure you wish to enable ID Protection?", which is a great new notification IMO. BUT, when I click "yes", I receive this error message: ID Protection Toggle FailedDomain is already Private - No update made. needless to say, it unchecks the ID Protection box and doesn't save to reflect that it actually is/already is private. I use NameSilo as my registrar. I'm going to check in with them to make sure that I'm not missing an updated extension. I also use the Lara theme. I tried disabling the theme to make it through the Manage Orders page, just to make sure it wasn't the admin theme causing conflict. i received the same greyed boxes on that screen, so I'd have to assume that it isn't the theme. (which is totally awesome and very beautiful!!! I'd highly suggest the theme to any and all WHMCS admins out there. it's priced so amazingly for what you receive. honestly, the default WHMCS themes have really been lax IMO) - splaquet

I hope that it's not just me in this jam... otherwise this feature would have no meaning for anyone else the problem that i've found myself with is that when I first started using WHMCS a few years back, i totally failed to migrate over the domains properly. to avoid having my clients receive a ton of emails, i migrated them all to my email account and then reassigned them to the proper clients. if the problem i face isn't already obvious, whelp, about 75% of those domains are paid 1 year in advance of their actual expiration date. in turn, the yearly invoice that's generating actually reads for the next year. so if the invoice generates on 7/10/2017 and the the billing period *should* be for 8/10/2017-8/10/2018, it's actually showing the invoice generated on 7/10/2017, and billing period for 8/10/2018-8/10/2019 (as in, for the next year) i've learned that when i find these domains, to manually create an invoice to cover that year that was skipped. that was working great, for a little while at least... now i'm finding myself having to question whether the invoice that the client is paying (this only really happens with check payments) is the one that i've regenerated or the one that the system has generated. if it's mine, it wouldn't renew the domain for 1 more year. it's only pay for that skipped year and catch up. if it's the system, it would renew the domain for another year and i've contributed back into the vicious circle i created for myself. *** so, in realizing that this problem only applies to maybe 2% of all users, i've since found a solution that might be a practical feature for 75% or more users. if you look at the screenshots below, you'll see the problem that i was explaining above. i honestly cannot remember if the invoice here is one that i made or the system generated. i could probably do some research on the dates, etc, but that'd take A LOT of time for over 100 domains. here's my suggestion: - on the invoice page in the backend, how about display a field that shows the actual expiration date for the domain(s) listed within the invoice? - also on the invoice page backend, a simple checkbox that, checked off by default, can be unchecked to *not* "domain will automatically renew at registrar upon payment" it'd only have to be on invoices automatically generated by the system. since you'd be moving forward from the issue, you wouldn't even have to worry about creating new invoices and cancelling the system generated ones. thoughts? would anyone else benefit from this or am I still finding myself as a 1%er ? ** notice that my current band-aid that i've finally figured out is to remove the registrar assignment, so it doesn't automagically autorenew for another year. ...but, you can see here where creating a temporary fix to one problem is ultimately creating a potential new problem for down the road. setting the domain to autorenew at the registrar is the failsafe to this ** - splaquet

Have you tried: - changing their payment method from whatever it's currently set at, to something else - then, deleting their card info from whmcs - then removing their profile from your cc processor (the association might have disconnected) - then reassigning then back to old CC payment method Not sure if that'll work, but it worked for me once. Hopefully that'll help. Also, look in the log to see what error code that the processing attempt is giving you. Hopefully that'll help shed some light. - shannon

i realize that this post is years old, but i was running into the same error. i haven't totally tracked it down, but on my end at least, it seems to present itself when changing CC processors and the old gateway auth is still associated with the old processor. i changed processors and had to call up a handful of clients to have them update their card info. that's when i started running into it. i haven't found a quick solution yet, but i'll try and report back if i do.