CodeRelic.com

Over the last six months, I have been a part of the myMumble task force as the lead developer and infrastructure architect. We quietly launched the website on July 3rd and then made it official on July 5th by announcing the release through different media channels. The official “press release” is published on the myMumble website.

Free Mumble Server Provider

myMumble is a subsidiary of NationVoice Communications, the large VoIP communications leader. myMumble is not just another Mumble server provider. While other providers offer free trial servers, myMumble provides free life time five slot Mumble servers. I think that this will make a dent in the Mumble server hosting business and force the industry to adapt.

Anyway, enough of nonsense and hype.

The primary goal for me was to streamline the way that the myMumble business is operated and managed. Since it is a hosting business, WHMCS was obviously in my thoughts since the beginning. The core of the myMumble website is powered by WHMCS, but the landing page and some of the other secondary pages are built with the Kohana Framework.

One of the most important requirements for myMumble was to only have one username and password that the customers have to remember. It was also important that there was only one “panel” or “secure area” where the customer has to log in to. I did not want to use some hardly customizable third-party solution as the “control panel” for the Mumble servers, so I built my own from scratch as a module for WHMCS. It integration was quite simple and it fits well within the website.

Developing the code that actually communicated with the Mumble servers was simple. Mumble has reasonably good documentation for developers on their Wiki. The ICE module for PHP was the more secure and robust option for interfacing with Mumble servers, so I chose to use that for the module. I had never worked with the ICE extensions before, so I had an exciting time experimenting and learning with it. While the Mumble ICE class has some documentation, it was not that robust, so I had to do a lot of “guess and check” development.

For the WHMCS module, I had to build a completely custom provisioning routine for Mumbles since they required a more intense and product specific allocation and deployment logic that WHMCS did not support out of the box.

We have some other cool new stuff in the pipeline with myMumble. I hope to post some tech reviews about it in the coming weeks.

In a recent project for which I did all the custom development and systems integrations, I stumbled across a problem where WHMCS was not marking invoices as paid when a user paid via PayPal and returned to the website after paying. The invoice screen was confusing and had no indication of the payment that the user had just made.

First I thought that it was because PayPal was slow to send the IPN notification, but after waiting for some time and looking at logs, it turned out that the IPN notification had been received almost instantaneously, but the invoice was still marked as unpaid.

The Problem

After some digging, I figured it out. The problem was the the PayPal account had a primary email account and several aliases. An alias was being used for the project. When PayPal sent the IPN notification, it marked the receiver as the primary email for the account. This confused WHMCS because it was not the email that the system was configured with.

The Solution

In order to fix the issue, you have to put both the alias and the primary email in the PayPal configuration within WHMCS. Under “Setup > Payments > Payment Gateways” set your PayPal Email as “[email protected],[email protected]”

Now when a user goes to pay, they will send their payment to “[email protected]” but WHMCS will now recognize the IPN notification when it comes over with the recipient email address as “[email protected]”

The hacktivist group, UGNazi, took down WHMCS.com on Monday. The hackers gained access to the main WHMCS server by impersonating WHMCS staff and persuading the webhost, Hostgator, to hand over login credentials to the account. Once the hackers were in, they took down the website and made it redirect to the hacker group’s website. After a couple hours, WHMCS was able to regain control and restore their website and service. read more »

WHMCS by default requires that every order has a payment type associated with it regardless whether the order is free or not. This means that the default functionality of WHMCS is to display the payment options on the checkout form every time. This can be very confusing for a customer that expects a free product, but then is required to select a payment type.

On a current project that I am a part of, I had to remove the payment options for free checkouts. It turned out to be quite simple.

The Concept

The idea is to put a <div> around the payment options and set style=”display:none;” on the div if the order total is zero.

The Solution

In my project, I was using the Web20cart theme for the checkout pages. The concept will work for any of the cart themes that come with WHMCS and probably with any custom theme as well.

In templates/orderforms/web20cart/viewcart.tpl, find the code block that looks like this:

<h2>{$LANG.orderpaymentmethod}</h2>
  <div class="cartbox">{foreach key=num item=gateway from=$gateways}
    <label><input type="radio" name="paymentmethod" value="{$gateway.sysname}" onclick="{if $gateway.type eq "CC"}showCCForm(){else}hideCCForm(){/if}"{if $selectedgateway eq $gateway.sysname} checked{/if} /> {$gateway.name}</label>
    {/foreach}</div>

Put the codeblock inside a <div> that has a trigger for the style=”display:none;” attribute, so the payment options are hidden if the order total is zero dollars.

<div {if intval(substr($total,1,-4)) == 0}style="display:none;"{/if}>
  <h2>{$LANG.orderpaymentmethod}</h2>
  <div class="cartbox">{foreach key=num item=gateway from=$gateways}
    <label><input type="radio" name="paymentmethod" value="{$gateway.sysname}" onclick="{if $gateway.type eq "CC"}showCCForm(){else}hideCCForm(){/if}"{if $selectedgateway eq $gateway.sysname} checked{/if} /> {$gateway.name}</label>
    {/foreach}</div>
</div>

WHMCS offers an SEO friendly URLs option in the adminstration panel. The steps to enable them are documented in the official support center article, so check there for how to enable them.

Search Engine Friendly URLs are where a URL which once was “/knowledgebase.php?action=view&id=1″ becomes “/knowledgebase/1/How_do_I_access_my_control_panel.html”. You can enable these for the announcements, downloads and knowledgebase sections of the WHMCS client area.

I recently had to setup WHMCS 5 on a brand new cloud server running a fresh LAMP install on Debian. I had to install curl and ioncube… no problems there. I uploaded WHMCS and configured it with the official instructions and got everything working. In the admin panel, I wanted to enable SEO friendly URLs for the website, so I checked the associated box and hit save. I also renamed the htaccess.txt to .htaccess as instructed. At first everything seemed to work properly, I could navigate to the knowledge base, downloads, and announcement sections.

The Problem

The problem was that after I added some articles to the knowledgebase and tried to go view the article, the SEO URL appeared in my browser’s URL bar, but the page stayed on the main Knowledgebase index with the categories and most viewed articles.

The Solution

I was baffled for a little bit. I double checked my .htaccess file, made sure mod_rewrite was installed and working, but I couldn’t find what was wrong. After some digging around it turned out that the Apache installation that I had on my server was configured with “Options +MultiViews” as default. The solution was to add “Options -MultiViews” to the top of the WHMCS .htaccess file. Everything started working as expected.

We just upgraded our server software for our StarAuto CMS product and we came across a new Apache restart issue with Plesk 10.4 after a new account is created. Our WHMCS installation was also upgraded to 5. By default, Plesk 10.4 does a hard restart after any account creation or modification action, but we can’t have the service be interrupted abruptly for a few moments when ever a new client website is setup, so we had to browse around and figure out a solution.

The solution is to add a record to the Plesk (psa) database on the server where Plesk is installed. First, log in to MySQL as root (admin) and switch to the psa database. Then run the following insert to enable graceful Apache restarts.

INSERT INTO misc VALUES ('restart_apache_gracefully', 'true');

By using this method, which is actually outlined in the Parallels knowledgebase, you no longer have to use the nasty work around that we used and explained in our previous post, “Integrating WHMCS 4.x with PLESK 10“, about getting around the hard Apache resets.

Our service runs on a DV server from MediaTemple and we change our admin account password frequently for security reasons, but the root password for MySQL doesn’t change automatically, so we had forgotten our root MySQL password (silly), so we retrieved it by following the instructions from Plesk.

On server with Parallels Plesk Panel versions 8.x, 9.x and above admin password is stored in file /etc/psa/.psa.shadow. Use the following command to get the password:

~# cat /etc/psa/.psa.shadow

Since version 10 admin password stored in file /etc/psa/.psa.shadow is encrypted. Use the following command to get admin password in plain text:

~# /usr/local/psa/bin/admin –show-password

Despite version of Parallels Plesk Panel you may use the following command to login to mysql with root privileges:

~# mysql -uadmin -p`cat /etc/psa/.psa.shadow`

WHMCS 4.x comes with built-in support for PLESK 10, but when you enable the functionality, you will notice that when an account is created, the server will stop responding. This happens because PLESK 10 uses the websrvmng utility improperly. When a new account is created, PLESK issues a hard restart with the utility instead of a soft restart. This causes the entire server to stop responding for a moment and the user on the website will receive a server not responding screen during their checkout. This is obviously unacceptable.

The easiest solution is not to fix PLESK, but change websrvmng to always issue soft restarts instead of hard restarts. This will keep your web server up and running and your customers will not be scared away by a server not responding page.

To fix websrvmng, first find where it is on your server. Generally it is located in:

/usr/local/psa/admin/sbin/

Once you have found websrvmng, rename it to websrvmng.original:

mv websrvmng websrvmng.original

Then create a new file called websrvmng and paste in the following code:

#!/usr/bin/perl
 
my $commands='';
 
foreach $argnum (0 .. $#ARGV)
{
    $commands .= ' ' . $ARGV[$argnum];
}
 
if($commandline =~ /--restart/)
{
    system("/etc/init.d/httpd graceful");
}
else
{
    $cmd = "/usr/local/psa/admin/sbin/websrvmng.original $commands";
    system($cmd);
}

Once you have created the new websrvmng, grant the correct permissions to it so that it can be executed.

chmod 750 websrvmng

That is all you should have to do. Now when PLESK calls the websrvmng that you created, it will issue a soft restart when needed while processing all other requests normally by using the real websrvmng which is now called websrvmng.original

Now when a user goes through the sign up process on your WHMCS system, the server should no longer go unresponsive during their check out.