twikamltd

Thanks for the pricing update WHMCS, our pricing is only going up 5000% instead of 8400%. 🤣 What planet are you on? Of other hosts I know that use WHMCS at this level, guess how many tell me they're going to start paying these rates? Zero. I think WHMCS may have over-estimated their value to us here 😂

Same here, showing as unlicensed.

You're allowing us to spread our $120 a year update payment over 12 easy monthly payments of $849.95? That's really good of you, thanks guys!!!

Chris, Do you consider a price increase of 85x to be reasonable? Also on the new pricing, once you go 1 customer over 10k, your price goes from $249 to $849? Can you just admit what's going on, which is a huge, greedy cash grab. I've never even heard of a price increase of around 8400% before. There is literally no justification for it, you know it, we all know it.

John, in your opinion, do you think an increase from paying for updates as normal at $10/mo, to $849.95 per month is acceptable? I mean, do you think that's reasonable? An 85x price increase as we're just over 10k active users?

Ah, just found it, you have to change the value on the tablelist include to: noSortColumns="0" startOrderCol="1" filterColumn="4"

Created a child theme of 21, copied clientareadomains.tpl. Removed the th and td as normal to remove the SSL icons from the domain table when clients view their list of domains, but then table doesn't load, just get the jquery Loading.... Any ideas please? I've already had to apply the 16026 hotfix.

Damn it! Didn't see that! Any pointers for how to hook the ticket dept layout instead of altering the template file please? Will save updating the file on each upgrade. I can't see any obvious hook that'll do it.

Forgot to count Open tickets as well as Customer-Reply: <?php use Illuminate\Database\Capsule\Manager as Capsule; function get_support_depts_tickets_hook($vars) { // Query for ticket counts $ticketdeptstats = Capsule::table('tbltickets') ->select('did', 'status', Capsule::raw('count(*) as numtickets')) ->groupBy('did', 'status') ->get(); $encodedata = json_encode($ticketdeptstats); $decodedata = json_decode($encodedata, true); // Query for number of pending orders $pendingordernum = Capsule::table('tblorders') ->where('status','Pending') ->count(); // Query for number of pending tickets $pendingticketnum = Capsule::table('tbltickets') ->where('status','Customer-Reply') ->orWhere('status','Open') ->count(); // Query for number of overdue tickets $overdueinvnum = Capsule::table('tblinvoices') ->where('status','Unpaid') ->whereDate('duedate','<',date('Y-m-d')) ->count(); return array("ticketdepartmentstats" => $decodedata, "pendingordernum" => $pendingordernum, "pendingticketnum" => $pendingticketnum, 'overdueinvnum' => $overdueinvnum); } add_hook("AdminAreaPage", 1, "get_support_depts_tickets_hook");

Right, after upgradeing to 8.0.4, was thoroughly disappointed to see the pending orders, tickets and overdue invoices disappear, so here's the solution: Hook: <?php use Illuminate\Database\Capsule\Manager as Capsule; function get_support_depts_tickets_hook($vars) { // Query for ticket counts $ticketdeptstats = Capsule::table('tbltickets') ->select('did', 'status', Capsule::raw('count(*) as numtickets')) ->groupBy('did', 'status') ->get(); $encodedata = json_encode($ticketdeptstats); $decodedata = json_decode($encodedata, true); // Query for number of pending orders $pendingordernum = Capsule::table('tblorders') ->where('status','Pending') ->count(); // Query for number of pending tickets $pendingticketnum = Capsule::table('tbltickets') ->where('status','Customer-Reply') ->count(); // Query for number of overdue tickets $overdueinvnum = Capsule::table('tblinvoices') ->where('status','Unpaid') ->whereDate('duedate','<',date('Y-m-d')) ->count(); return array("ticketdepartmentstats" => $decodedata, "pendingordernum" => $pendingordernum, "pendingticketnum" => $pendingticketnum, 'overdueinvnum' => $overdueinvnum); } add_hook("AdminAreaPage", 1, "get_support_depts_tickets_hook"); At the top of sidebar.tpl (literally line 1): <div class="sidebar-header"> Overview </div> <ul class="menu"> <li><a href="orders.php?status=Pending">{$pendingordernum} {$_ADMINLANG.stats.pendingorders}</a></li> <li><a href="supporttickets.php">{$pendingticketnum} {$_ADMINLANG.stats.ticketsawaitingreply}</a></li> <li><a href="invoices.php?status=Overdue">{$overdueinvnum} {$_ADMINLANG.stats.overdueinvoices}</a></li> </ul> Then put the slightly updated Kayako style ticket view code starting at line 137: <div class="sidebar-header"><img src="images/icons/tickets.png" alt="Filter Tickets" width="16" height="16" class="absmiddle" /> {$_ADMINLANG.support.department}s</div> <ul class="menu"> {foreach from=$ticketdepts item=dept} <li style="margin-left: 10px;">{$dept.name}</li> {* Now display direct links to the department tickets of each status *} <ul class="menu" style="margin-left: 13px"> {foreach from=$ticketstatuses item=status} <li> -<a style="display: inline;" href="supporttickets.php?deptid={$dept.id}&view={$status.title}">{$status.title}</a> {foreach from=$ticketdepartmentstats item=ticketdepartmentstat} {if $dept.id eq $ticketdepartmentstat.did && $ticketdepartmentstat.status eq $status.title} ({$ticketdepartmentstat.numtickets}) {/if} {/foreach} </li> {/foreach} </ul> {/foreach} </ul> (goes inbetween the elseif if) Good luck, WHMCS, can we make this standard?!

We're also seeing this on 0.00 orders, making free domain transfers very difficult. John, you can't seriously be saying 'by the end of the year' for this, all UK hosts offering free *.uk transfers (most of them) are affected by this!

So it's definitely Worldpay pay methods being sent to the Stripe gateway in our case, I modified the Stripe gateway (don't ask how) to check for Worldpay Futurepay IDs and return as declines instead, and now the payment cron is fine. In other words, there's a logic bug somewhere else in the WHMCS code allowing this to happen.

So one thing I've been able to see is: If an invoice is set to Stripe, but the client only has a different pay method saved, with a token ID for Worldpay Futurepay in our case (and yes the pay method is set to Worldpay Futurepay), then the cron still tries to use that Worldpay FP pay method with the Stripe gateway and that is causing the failure. I'm now loathed to remove all Worldpay pay methods as I've spent a couple of days making sure everything looks perfect in the database.

If you just want to dump all your tokens to see if there's any weird ones. Can't find any in ours. <?php // Include WHMCS for API functions include('init.php'); $table = "tblpaymethods"; $fields = "id,userid"; $result = select_query($table,$fields); while ($data = mysql_fetch_array($result)) { // Get pay methods if client exists $command = 'GetPayMethods'; $postData = array( 'clientid' => $data['userid'], 'paymethodid' => $data['id'] ); $pm_results = localAPI($command, $postData); //print_r($pm_results); echo "PMID: ".$data['id']." token: ".$pm_results['paymethods'][0]['remote_token']. "\n"; }

Same issue here. What I'm seeing is the cus_ token gets converted to the JSON version with a method added after a successful manual capture from the admin area. If the card is declined that doesn't happen though, which is to be expected. What I can't see is which it's tripping up on. I've verified the tblpaymethods, tblcreditcards and tblbankaccts tables are all clean and look ok, and also removed any paymethods which had no cus_ tokens.