Fr3DBr

If we modify the default currency of WHMCS and Click on the Update Exchange Rates button to update all other currencies to the new default and Update Product Prices to set the prices accordingly. Will it update the "current products" for every customer, or only the products for future purchases in the website ?

Hi @oneawesomeguy, is this problem happening with reseller packages ? I bet so, right ?

It seems to be related with a cPanel API issue: https://forums.cpanel.net/threads/whm-62-build-19-20-listpkg-api-bug.597663/

I'm facing the same problem too, v7.1.2 what's happening ? It was working fine for about 3 years, now it just doesn't ??? For some reason the change package function, gets "access denied" when trying to list packages from the cPanel server, although you can see the packages in the cPanel module configuration when you're editing the product/service just fine, so it seems to be an issue related to change package function only...

Hi, guys. Why the database interaction with Capsule, isn't working the same way as in Laravel ? Capsule::table('tblinvoices')->where('status', 'Unpaid')->where('duedate', '<=', 'DATE(DATE_ADD(NOW(), INTERVAL -2 DAY))')->get() When I use this statement, I'm getting invoices that I'm not supposed to, because it is ignoring the "<=" operator, any thoughts of why is this ? Also tried this one: Capsule::table('tblinvoices')->where([ ['status','=','Unpaid'], ['duedate', '<=', 'DATE(DATE_ADD(NOW(), INTERVAL -2 DAY))'], ])->get() Where the result is still the same, getting invoices with a duedate of 2017/04/02 when it wasn't supposed to happen. Ok, I could only fix it, by using whereRaw(): Capsule::table('tblinvoices')->whereRaw("status = 'Unpaid' AND duedate <= DATE(DATE_ADD(NOW(), INTERVAL -2 DAY))")->get() But actually, it was supposed to work the way I've shown above before, wasn't it ?

Ah :) This explains it. Thanks.

Nevermind, it works fine.

Hi, guys. I've tried this: php -q crons/cron.php skip --AutoSuspensions --CurrencyUpdateExchangeRates --UpdateServerUsage Although, while the default --email-report is 1 when using skip switch, no e-mails are sent. Not even when you force it as: php -q crons/cron.php --email-report=1 skip --AutoSuspensions --CurrencyUpdateExchangeRates --UpdateServerUsage Any ideas ?

I did exactly this before, but the result was exactly the same too.

Hi, guys. In WHMCS V6, my template is working just fine, to include php files, however now I'm testing V7 and I've noticed a problem: Smarty Error: Syntax error in template "file:/home/webpath/public_html/templates/mytemplate/header.tpl" on line 69 "{include_php file="$template/header_ex.php"}" {include_php} file 'mytemplate/header_ex.php' is not readable What could be the reason for this ? The php file is located in the template directory, together the tpl files, and as I said in V6 it works fine ?

Hi, guys. I'm not even touching MySQL in my code yet, but by just using Zend/XML-RPC extension (for some unknown reason), the MySQL Database handler is lost: Warning: Error while sending STMT_PREPARE packet. PID=6322 in /home/xxx/public_html/vendor/illuminate/database/Illuminate/Database/Connection.php on line 278 Fatal error: Uncaught exception 'Illuminate\Database\QueryException' with message 'SQLSTATE[HY000]: General error: 2006 MySQL server has gone away (SQL: select `domain`, `username` from `tblhosting` inner join `tblproducts` on `tblproducts`.`id` = `tblhosting`.`packageid` where `server` = 2 and `type` = reselleraccount and `domainstatus` in (Active, Suspended)) (SQL: select `domain`, `username` from `tblhosting` inner join `tblproducts` on `tblproducts`.`id` = `tblhosting`.`packageid` where `server` = 2 and `type` = reselleraccount and `domainstatus` in (Active, Suspended))' in /home/xxx/public_html/includes/classes/WHMCS/Terminus.php:0 Stack trace: #0 [internal function]: WHMCS\Terminus->whmcsExceptionHandler(Object(Illuminate\Database\QueryException)) #1 {main} thrown in /home/xxx/public_html/includes/classes/WHMCS/Terminus.php on line 0 Any ideas in how I could prevent this ? Or at least, force a "restore" of the default database handler ?

We do this, although since it interfere a bit with the login procedure, I'd like to know if we can only do not do this when using the Login API, get it ? Everything else is sanitised.

I would like to get a reply from whmcs staff, as their documentation doesn't says anything about it anyways.

The "should" in the sentence is what makes me afraid haha.

Hi, guys. Is the login API from whmcs, safe to use without sanity checking on user supplied strings ?