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! 🙂