ezyweb

I have a range of custom client fields that cover a variety of purposes, but I don't want them all to show all the time in the clientareadetails.tpl. Can you advise me on how do the following ... Show only one specific custom client area field with its label, value and description Show only a specific range of custom client fields, eg, id 100-150, if a client has an specific active service, or has a service active on a specific server. I've tried about 60 different ways so far, and I just seem to crack it. Could someone please provide sample code to assist me in achieving these outcomes?

That's excellent, Steven. Thank you. We found it was necessary to add a column to the table dealing with this data for our module, but that was an easy fix once we understood where to place the additional variable. However, because that variable is now considered "required" by the addbillingitem API, leaving it out altogether would have left our code the way it was .. broken. Adding it fixed the issue straight away. Thanks so much for your help.

Hi everyone, We've just upgraded to the latest version of WHMCS and that's presented a couple of issues with some of our custom modules. After the module in question queries the server for reporting and billing data, we then ask it to add "Next Invoice" billable items with that data. However, we're now getting the following error, and I wondered if someone might be able to point in the right direction to quickly fix this issue. ... Invalid Unit, please specify either ‘hours’ or ‘quantity’ I can see that our module has been using "period", but if we change all of those to, eg, "hours", the module errors again saying that we're calling an incorrect database table. Could someone point in the right direction to get this fixed? Kerry

G'day folks! I'm hoping someone can help me with the correct Laravel structure for the following query ... UPDATE radreply SET value=(SELECT ip FROM radip WHERE allocated='$username') WHERE value='' AND username='$username' Your help will be greatly appreciated. Kerry

Yes, bear, but we have some specific modifications to their original module which need to be carried over to the new module's code. It that I need help with, as mentioned in the OP ...

That might be true if you're a developer working with code all the time, but that's not me. The reason this needs updating is because, for legitimate reasons, we've been forced to keep one of our WHMCS installations at v5.x.x, so the old code was more than suitable until now. However, we're finally in a position to update WHMCS, so there's an obvious need to move to the new version of their FreeRadius module. While I appreciate you taking the time to respond and for the links, these are things I've already found using our old friend Google, but to be honest, they're not much help because, as mentioned before, I'm not really a code guy. What I'm hopeful of is some specific assistance and/or code suggestions in fixing the updated code I've attempted to use as inserted above, so that it actually works as expected. I realise that you make your living doing development work, so my request may be out of line in asking for free assistance, but this is where the WHMCS support guys pointed me, so here I am asking.

G'day everyone .. I'm hoping someone can help me, please. We're using the WHMCS FreeRadius module to provision and manage DSL and NBN tails for our customer, but we need a couple of extra elements added to it. Matt Pugh was really helpful with the previous version, but now that cPanel has partnered with WHMCS, they no longer offer the kind of fairly simple assistance he did. So, here goes ... This is the original code that still works if we use the old module $query = "UPDATE radip SET allocated=('$username') WHERE allocated='' LIMIT 1"; $result = mysql_query($query,$nbnconnectsql); if (!$result) { $nbnconnectsqlerror = mysql_error(); nbnconnect_WHMCSReconnect(); return "FreeRadius Database Query Error: ".$nbnconnectsqlerror; And here's the code I'm trying to add into the new version of the module $nbnconnectsql ->from('radip') ->where('allocated', '=', '') ->update(array( 'allocated' => $username, )) ->limit(1); But the latter keeps throwing the following error, and for the life of me, I can't work out why Module Command Error FreeRadius Database Query Error: SQLSTATE[42S22]: Column not found: 1054 Unknown column 'username' in 'where clause' (SQL: update `radip` set `allocated` = LOC000012345678@domain.net.au where `username` = LOC000012345678@domain.net.au) Where the heck is it getting the "username" column from?? Once the action above is working, we then need it to do the following (old code first that works, followed by the new that I'm stuck on) ... OLD and working $query = "UPDATE radreply SET value=(SELECT ip FROM radip WHERE allocated='$username') WHERE value='' AND username='$username'"; $result = mysql_query($query,$nbnconnectsql); if (!$result) { $nbnconnectsqlerror = mysql_error(); nbnconnect_WHMCSReconnect(); return "FreeRadius Database Query Error: ".$nbnconnectsqlerror; } NEW and likely wrong $query = $nbnconnectsql ->from('radip') ->select('ip') ->where('allocated', '=', $username); $nbnconnectsql ->from('radreply') ->update('value', '=', '$dedicatedip') ->where('value', '=', '') ->where('username', '=', $username); We then need it to update the WHMCS tblhosting table ... OLD and working $query = "SELECT ip FROM radip WHERE allocated='$username'"; $result = mysql_query($query,$nbnconnectsql); $data = mysql_fetch_array($result); $ipaddr = $data[0]; nbnconnect_WHMCSReconnect(); update_query("tblhosting",array("dedicatedip"=>$ipaddr),array("id"=>$params['serviceid'])); return "success"; NEW ... I have no idea how to do this with Laravel, so any help will be greatly appreciated. Thanks in advance for your input.

Hi Brian, Thanks for the reply. I'm aware of the use of the crosshairs to adjust the sorting in the admin area, and this had obviously been done. But I've now discovered what the issue is. For some reason, even when using the crosshairs to sort the products into the relevant order in the admin area, the "order" table in the database remains filled with "0" for every product, which causes the problem of the incorrect order on the products.tpl. I'm now going through the database to manually add the sort order for each product, and now their displaying correctly, but only once I returned the code back to its default of ... {foreach $products as $product} Thanks for your help. This tweak has been really helpful knowing regardless of whether I need to use it at this time or not.

I incorrectly said, "What we're looking for is a way to sort the products according to the "sort" column from the products database." What I meant was, "What we're looking for is a way to sort the products according to the "order" column from the products database."

G'day Brian! Thanks for the code to enable better sorting of the products in our order forms, but there's a tweak we're keen to make, but can't seem to work out how. So I'm hoping you can help. Because not all of our products have been added in order, sorting by $pid doesn't work in every category. What we're looking for is a way to sort the products according to the "sort" column from the products database. This would ensure that regardless of $pid, the products would always be presented to our customers in exactly the way we intend from our backends. I'm hoping you can help. Cheers!

We're experiencing the exact same problem. Could you describe the fix and how you achieved it?

The thing is, Chris, the backups don't "cripple" my server in any way. Site load speeds might slow down very slightly, but the VM otherwise keeps performing quite normally .. just with its CPU at or near 100% for the duration of the backup part of the cron run. Every other aspect of the daily cron runs and completes exactly as normal. It's only the backup that does not complete. Additionally, an hour later, my second WHMCS installation's cron runs with exactly the same CPU load behaviour, but it seems because the database is only about 60MB, the backup also completes without issue. Also, the physical host server isn't even breaking a sweat. With CentOS/top reporting 100% usage, the actual host reports the VM in question is always running at below 50% of its allocated CPU capacity. That's a part of the reason this behaviour is so hard to nail down and deal with. That's why I suspect this has something to do with the php script itself, and has little if anything to do with hardware as othello has suggested. PM on its way to you.

I should also add that I ran iostat while the manual backup was running, and got the following results: %user %nice %system %iowait %steal %idle 1.61 0.18 1.22 0.21 0.00 96.77 There is no increase in iowait even with the script running, but running top reveals CPU is almost constantly at 100%.

Hi Chris, I can confirm that this particular VM and its host, absolutely scream under any other conditions. We've only found two things that cause these kinds of CPU spikes .. 1) the WHMCS daily cron and 2) the latest ownCloud software which we've been testing. Besides that, if this VM runs at anything much higher that a 1% load, it would be working hard. We can create and decompress big tarballs, do manual MySQL dumps and so on, all with no issue at all and at full speed and performance .. but try to run the WHCMS cron .. and that's another story. I'll take your advice and try running the option flags against the cron, but I don't think it will make much difference, especially if Don and John believe that 20Mb+ shuts the backup feature down. iostats display the following: 03/08/2013 _x86_64_ (8 CPU) avg-cpu: %user %nice %system %iowait %steal %idle 1.61 0.18 1.22 0.21 0.00 96.77 No red flags there that I can see, especially with a 0.21% iowait. Kerry

Hi guys, I've heard back from both John and Don from WHMCS Support about this matter. They've told me the following: Don: "As your database size is currently around 175MB, it is too big for the built in backup tool to be able to handle. Unfortunately being that big simply means that for a PHP script to loop through and save that data into temporary memory in order to generate a full backup is not possible - either the memory limits or max execution time limits on the server side of things will kick in way before that completes and terminate the script." I then asked how our friend Rob "othello" Golding was managing to achieve a full backup of a 603MB database, and received the following answer: John: "I'm not sure how Othello is managing that, you'd be best off asking him directly. In our experience it's not possible to backup databases at or above about 20MB with a standard PHP configuration." Obviously I was having no problems with the daily backups of my database until it reached about 170MB, which tells me I had my PHP tweaked pretty well for my environment, and that this seems to have nothing to do with disk I/O or even CPU. Having said that, I'd be keen to hear from you, Rob, as to how you're achieving PHP-scripted backups of a 603MB WHMCS database, when it's supposedly not possible to do. Any insight on PHP/System settings you can provide that might help us get more out of the inbuilt backup feature would be much appreciated. Kerry