Space or special characters in the hostname breaking the auto-provisioning

[Hannan]

Hi Guys,

When a client uses a none standard hostname during an order and uses any special character or space in the hostname then is breaking our auto-provisioning module so the VPS is not creating. So we have to manually review the order and change the hostname. I was wondering how we can add a custom code to fix this issue?

1. Code to automatically removes the space and special characters.

2. Not letting the customer pass the page and gives him/her an error to fix it

What do you think?

Thanks

[twhiting9275]

This is one of those things that really should have been fixed quite some time ago. Force standardization, please!!!

Here you go. Save this as a php file in whmcs/includes/hooks

Read through it, pretty straightforward to figure out what it's talking about

<?php
/*
Hook to automatically correct domains that are syntaxcally invalid (special characters)
Provided courtesy of https://www.whmcs.guru/
*/

if (!defined("WHMCS"))
die("This file cannot be accessed directly");
use Illuminate\Database\Capsule\Manager as Capsule;


function guru_strip_special($vars)
{
	//certain types of characters won't screw with the hostname. Why not allow them?
	//in some cases, these are necessary (ie: period for example)
	$valid_special = array('-', '_', '.');


	//grab the order
	$orderid = $vars['orderid'];

	//get the hostname from  the database
	$mystring = Capsule::table('tblhosting')->select('domain', 'id')->WHERE('orderid', $orderid)->get();
	foreach ($mystring as $data)
	{
		$myid = $data->id;
		$hostname = $data->domain;
		//no domain, no bother
		if (empty($hostname))
		{
			return;
		}

		if(!ctype_alnum(str_replace($valid_special, '', $hostname))) {

		$hostname = htmlspecialchars_decode($hostname);
			
			$nhost =preg_replace("/[^\w-\p{L}\p{N}\p{Pd}\$\.€%']/", "", $hostname);
			$nhost  = str_replace("%", "", $nhost);
			$nhost  = str_replace("\$", "", $nhost);
			$r2=Capsule::table('tblhosting')->where('id', $myid)->update(array('domain' => $nhost));

		}
	}
}

add_hook("AcceptOrder",1,"guru_strip_special");

This will take a non standard hostname (anything without a-z, 0-9, -, _ or .) and standardize this. It'll then update the WHMCS database accordingly.

 

This will not update the first invoice (sorry, there's no easy way to do that one), however, this will correct the database so that when the client logs in, they'll see the corrected hostname.

I ran this through about a zillion checks to get this right, looks like this is good, but if you see other things, let me know

 

[Hannan]

54 minutes ago, twhiting9275 said:

This is one of those things that really should have been fixed quite some time ago. Force standardization, please!!!

Here you go. Save this as a php file in whmcs/includes/hooks

Read through it, pretty straightforward to figure out what it's talking about

<?php
/*
Hook to automatically correct domains that are syntaxcally invalid (special characters)
Provided courtesy of https://www.whmcs.guru/
*/

if (!defined("WHMCS"))
die("This file cannot be accessed directly");
use Illuminate\Database\Capsule\Manager as Capsule;


function guru_strip_special($vars)
{
	//certain types of characters won't screw with the hostname. Why not allow them?
	//in some cases, these are necessary (ie: period for example)
	$valid_special = array('-', '_', '.');


	//grab the order
	$orderid = $vars['orderid'];

	//get the hostname from  the database
	$mystring = Capsule::table('tblhosting')->select('domain', 'id')->WHERE('orderid', $orderid)->get();
	foreach ($mystring as $data)
	{
		$myid = $data->id;
		$hostname = $data->domain;
		//no domain, no bother
		if (empty($hostname))
		{
			return;
		}

		if(!ctype_alnum(str_replace($valid_special, '', $hostname))) {

		$hostname = htmlspecialchars_decode($hostname);
			
			$nhost =preg_replace("/[^\w-\p{L}\p{N}\p{Pd}\$\.€%']/", "", $hostname);
			$nhost  = str_replace("%", "", $nhost);
			$nhost  = str_replace("\$", "", $nhost);
			$r2=Capsule::table('tblhosting')->where('id', $myid)->update(array('domain' => $nhost));

		}
	}
}

add_hook("AcceptOrder",1,"guru_strip_special");

This will take a non standard hostname (anything without a-z, 0-9, -, _ or .) and standardize this. It'll then update the WHMCS database accordingly.

 

This will not update the first invoice (sorry, there's no easy way to do that one), however, this will correct the database so that when the client logs in, they'll see the corrected hostname.

I ran this through about a zillion checks to get this right, looks like this is good, but if you see other things, let me know

 

Yes, it is one of the annoying problems.

Thank you very much. I did try it. Unfortunately, the order still would fail and if you try to accept it from the Admin area then it will work. Any solution so the order gets processed?

[twhiting9275]

You'll have to adjust that hook line a bit. The order itself shouldn't fail. The provisioning module will however.

So, if you provision before you accept the order, then you're going to run into problems. In that case, change 

add_hook("AcceptOrder",1,"guru_strip_special");

to

add_hook("AfterShoppingCartCheckout",1,"guru_strip_special");

This will process that hook after the checkout

Or you can change it to

add_hook("OrderPaid",1,"guru_strip_special");

which will run the time that first invoice is paid

They're both essentially the same thing

[Hannan]

11 minutes ago, twhiting9275 said:

You'll have to adjust that hook line a bit. The order itself shouldn't fail. The provisioning module will however.

So, if you provision before you accept the order, then you're going to run into problems. In that case, change 

add_hook("AcceptOrder",1,"guru_strip_special");

to

add_hook("AfterShoppingCartCheckout",1,"guru_strip_special");

This will process that hook after the checkout

Or you can change it to

add_hook("OrderPaid",1,"guru_strip_special");

which will run the time that first invoice is paid

They're both essentially the same thing

I have tried both and unfortunately, both failed! So basically I ordered then paid the invoice with the credit I had in the account. However this time it would not still change it from Admin area when clicking on 'Accept Order'.

It seems it does not trigger the hook after clicking on 'Check Out' 

Thanks

 

[twhiting9275]

If you go to your account -> services , select the service, what do you see in there for the hostname

[brian!]

13 hours ago, Hannan said:

2. Not letting the customer pass the page and gives him/her an error to fix it

you could use a simple HTML5 pattern in the template to display an error if any character is entered that is unacceptable to the pattern, e.g if you change in configureproduct.tpl...

<input type="text" name="hostname" class="form-control" id="inputHostname" value="{$server.hostname}" placeholder="servername.yourdomain.com">

to...

<input type="text" name="hostname" class="form-control" id="inputHostname" value="{$server.hostname}" placeholder="servername.yourdomain.com" pattern="[a-zA-Z0-9]+" oninvalid="this.setCustomValidity('Please use alphanumeric characters only')" oninput="setCustomValidity('')">

it will prevent any non-alphanumeric characters, including spaces, from being accepted in this field - if the user enter invalid characters, the order process won't continue until they correct the issue.

the error message can be customised to suit your needs, and if necessary can use Language Override strings to display an error in the users own chosen language.

hopefully, this will remove any issue before you even get to the provisioning stage.

[Hannan]

5 hours ago, brian! said:

you could use a simple HTML5 pattern in the template to display an error if any character is entered that is unacceptable to the pattern, e.g if you change in configureproduct.tpl...

<input type="text" name="hostname" class="form-control" id="inputHostname" value="{$server.hostname}" placeholder="servername.yourdomain.com">

to...

<input type="text" name="hostname" class="form-control" id="inputHostname" value="{$server.hostname}" placeholder="servername.yourdomain.com" pattern="[a-zA-Z0-9]+" oninvalid="this.setCustomValidity('Please use alphanumeric characters only')" oninput="setCustomValidity('')">

it will prevent any non-alphanumeric characters, including spaces, from being accepted in this field - if the user enter invalid characters, the order process won't continue until they correct the issue.

the error message can be customised to suit your needs, and if necessary can use Language Override strings to display an error in the users own chosen language.

hopefully, this will remove any issue before you even get to the provisioning stage.

Thank you guys for your prompt response.

I think this would be better.

Just one thing we use Modern orderform  and I have changed the code from:

<input type="text" name="hostname" size="15" value="{$server.hostname}" />

to

<input type="text" name="hostname" size="15" value="{$server.hostname}" pattern="[a-zA-Z0-9]+" oninvalid="this.setCustomValidity('Please use alphanumeric characters only')" oninput="setCustomValidity('')" />

and some other variation. Unfortunately did not work. 

Sorry I am not an expert with coding.

Could you please let me know what is the problem?  I suspect because the template is not HTML5? and what is the solution?

Thanks

[Hannan]

UPDATE: I have changed the order form from Modern to Standard Cart and it fixed.

Just you have missed a dot in the code. So it would be

<input type="text" name="hostname" class="form-control" id="inputHostname" value="{$server.hostname}" placeholder="servername.yourdomain.com" pattern="[a-zA-Z0-9.]+" oninvalid="this.setCustomValidity('Please use alphanumeric characters only')" oninput="setCustomValidity('')">

 

[twhiting9275]

Don't forget - and _ . Those are 100% valid characters when dealing with both servers, and domains.

[brian!]

sorry - I assumed you were using Standard_Cart...

although still shipped with WHMCS, Modern hasn't been updated in years.

https://docs.whmcs.com/Standard_Order_Form_Templates#Modern

Quote

The (Boxes & Modern) shopping carts no longer receive updates and may not be compatible with the latest features. They are provided for legacy users only.

9 hours ago, twhiting9275 said:

Don't forget - and _ . Those are 100% valid characters when dealing with both servers, and domains.

good spot - it should really be...

<input type="text" name="hostname" class="form-control" id="inputHostname" value="{$server.hostname}" placeholder="servername.yourdomain.com" pattern="[a-zA-Z0-9._-]+" oninvalid="this.setCustomValidity('Please use alphanumeric characters only')" oninput="setCustomValidity('')">

On 2/8/2018 at 02:36, twhiting9275 said:

This is one of those things that really should have been fixed quite some time ago. Force standardization, please!!!

+1 to that... sometimes you can use something so often that you miss the glaring holes in the program... but the minute you take a step back, or a user points out an issue, you think WTH are the developer's thinking by not fixing something so trivial yet important in the order process.

mind you, if a billing program now can't even calculate tax correctly, then i'm starting to wonder what we're all doing here.