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

The database is only 175MB in size and is running on a cPanel VM with 8GB RAM, 8 CPUs assigned to it and is only driving a handful of WordPress and Joomla sites plus two WHMCS installations. There are only 5 other small, low spec VMs running on the host. The cPanel VM in question is our corporate webserver and is running off an extremely robust Dell host with ample hardware including two Xeon quad core CPUs, 32GB RAM and 15K SAS HDDs, so it's not like I'm taxing the host. So while I appreciate your input Rob, the response is a little glib and provides no beneficial insight. I'm sure you'd agree that dealing with the backup of a 175MB database shouldn't be causing these issues.

Hi John, I've also noticed that since the 1st March, all automatic backups have stopped in one of my WHMCS installations, but they continue to work fine on another. Since both of them are working from the same cPanel server, and both installations are the same WHMCS version, I'm at a loss to explain why this has broken. I've just run a manual backup (via Utilities > System > Database Status > Download Database Backup). It has not completed, and cPanel has just sent an "Excessive resource usage" alert with a process that has not been automatically killed. Something's definitely changed. I'm just not sure what it is. Any ideas?

I agree. If auto-provisioning was added, then this would be a module I would strongly consider.

Hi Josh, With respect, I think $60.00 a year is pretty steep to simply provide clients with some pretty buttons to control the power in their VMs. Any client who has a VM will most likely know how to either RDP to Windows and do a reboot, or SSH to Linux and do a "shutdown -r now". A one-time $60 owned license would be something I'd consider, but at $60 a year for what it does, it's just too expensive. Have you considered adding the ability to power on the VM if it has been Gracefully Powered Off? Otherwise it seems a bit pointless to be able to shut it down in the first place if you can't Power it On later. Kerry

I don't know whether you've found an answer to this problem yet, but the issue lies with how you first setup up the IPs for each element of DNP. If you chose the defaults of 127.0.0.1 for DNPServer and DNPEnterpriseServer, then trying to reach them from WHMCS will fail every time .. unless of course, you're running WHMCS off the DNP server, but why would you? What you need to do is change the IP of the DNPEnterpriseServer to a publicly accessible IP. Remember to update this new IP in the DNPPortal as well, or the GUI won't be able to communicate with anything. Do NOT add a hostname. This is not necessary for DNPEnterpriseServer and can cause more trouble than it's worth if you do. Now, update your DNP Server config in WHMCS to use the new publicly accessible IP for DNPEnterpriseServer, and everything will work exactly as its meant to.

If you're a Westpac merchant, this is a payment gateway module you can't do without! Steve's done a brilliant job of enabling us Westpac merchants to deal directly and seamlessly with Westpac's API without the added annual costs of a third party gateway like eWay. If you're an Australian Westpac merchant, talk to them about having your facility converted to PayWay API, spend $99.00AUD with Sparky, and you'll be saving money on transactions right away. It'll the best $99 you'll ever spend on your business.

I'd be interested in this depending on the final price.

In the end, my only answer was to pay Sparky some money to have him fix up the code in the templates (which is apparently a bit of a mess), so now at least I can use them. But this is pathetic service on juiced's part. I reckon there's something very dodgy going on there though, since my tax invoice came from an ISP in Belgium (?!?) for a company based in New Zealand. What the ... ?? Anyway, once again, it's Sparky to the rescue. Thanks Steve!

Either I had a blonde moment or your post was a bit ambiguous. I'm guessing it was me being blonde! Looking forward to seeing the forum in action.

I've been watching this thread with interest but notice that your new "forum" mod is "powered by WordPress". How are you planning on making a blog platform work as a forum? They're totally different beasts. Not to be critical, but your "forum" even looks and feels like a blog. So which is it? And, does the license for WordPress allow for you to adapt it for use like this and, I presume, to then resell it? Kerry