brian!

are you using a custom theme and/or custom orderform ? if so, does the same thing occur when using "Six" and "Standard_cart" ?

In addition to what @Kian says, because you mention the client homepage, you could specifically use the ClientAreaPageHome hook rather than ClientAreaPage... but more than likely, you're thinking of outputting this either in a homepage panel or in an existing sidebar - each of which would require a different hook... basically, where/how you want to output this value will determine which hook to use.

oh fair enough if you just meant for now... basically, it should be any pricing-related table that has a 'decimal' type that currently uses 10,2 - if you write a SQL query to identify these tables, it will give you the following list (from v7.6b1 but I don't think there are any new tables in v7.6).. showing database table name and the decimal field(s) in that table to be edited. you could probably exclude changing tbltax => taxrate from the list - unless you need to add more decimal places to a tax rate e.g 17.555%... other than that reason, I don't think it's relevant to change tbltax => taxrate. no Kian said that, not me! no guarantees, but you should not. that's a legitimate concern, but if support have been suggesting this for years (unless there are elements in there going rogue lol), then I would think this to be low-risk in the long-term, but again no guarantees... although absolutely the best solution would be for WHMCS to do this themselves... I can't for the life of me see why they haven't done it already as they must be getting support tickets from users in countries where this would be applicable to their currencies.

did disabling captcha not make your custom orderform work? were there further issues with it that would have needed updating ?? it should still work... /* ***************************************************** ** Custom Stylesheet ** Any custom styling you want to apply should be defined here. ***************************************************** */ .navbar-main { background-color: rgba(58,58,58,1); } .navbar-main .navbar-nav > li > a:hover, .navbar-main .navbar-nav > li > a:focus, .navbar-main .navbar-nav > .active > a, .navbar-main .navbar-nav > .active > a:hover, .navbar-main .navbar-nav > .active > a:focus, .navbar-main .navbar-nav > .open > a, .navbar-main .navbar-nav > .open > a:hover, .navbar-main .navbar-nav > .open > a:focus { color: #fff; background-color: #000; } .navbar-main .dropdown-menu { background-color: rgba(58,58,58,1); } .navbar-main .navbar-nav .dropdown-menu > li > a:hover, .navbar-main .navbar-nav .dropdown-menu > li > a:focus, .navbar-main .navbar-nav .dropdown-menu > .active > a, .navbar-main .navbar-nav .dropdown-menu > .active > a:hover, .navbar-main .navbar-nav .dropdown-menu > .active > a:focus, .navbar-main .navbar-nav .dropdown-menu > .open > a, .navbar-main .navbar-nav .dropdown-menu > .open > a:hover, .navbar-main .navbar-nav .dropdown-menu > .open > a:focus { color: #fff; background-color: #000; } .dropdown-menu > li > a { color: #fff; } the above css wouldn't be a million miles away (colour-wise) from that used in the menu on your main website... the above was tested on a v7.6b1 dev, but I doubt the navbar css has changed significantly with earlier versions. sadly, like a lot of things with WHMCS, they seemingly expect you to either fix issues like this yourself, or get a developer in.... it's a similar situation with the menus/sidebars etc, in that they could have easily coded a menu manager into WHMCS and that would have significantly removed the need to use hooks to modify a menu... which btw no user should have been expected to learn/do, nor should users need a third-party addon or developer to simply modify a navbar menu (except perhaps in the most extreme of circumstances). I dread to think how much WHMCS support time, or even mine posting over the years for that matter lol, has been wasted on replying to threads about using hooks to modify the menus.

Hi Gary, I would still be inclined to think that it's your custom template and/or your orderform template... because if I change it to "Six" and "Standard_cart", it works fine. one thing that I did spot when changing to the above templates, was that standard_cart was using Google reCaptcha - whereas your custom templates didn't.... so i'm wondering if it's not getting a captcha response and treating it as a failed search... i'd suggest disabling captcha in setup -> general settings -> security and then seeing if your custom orderforms work.

any particular reason why not? it could potentially be years before WHMCS fix them and it's not the most extreme of solutions to do this.

$productID = [1,12]; // Replace with the ID of your Product/Service $userID = Capsule::table('tblorders')->leftJoin('tblhosting', 'tblorders.id', '=', 'tblhosting.orderid')->where('tblorders.id',$vars['orderid'])->whereIn('tblhosting.packageid', $productID)->first(['tblorders.userid']);

it's also worth noting that, as written, it runs after every order and changes the client group - regardless of the product(s) ordered.

i've no idea - I didn't write that hook (despite what it says in the header!)

@Kian in your absence, one of the WHMCS guys did recommend it - technically, it's hearsay, but it's never been denied... if support are now suggesting it in support tickets, i'd label that as "recommended"! anyway, it's not technically difficult to do - i've replied in numerous threads about it over the years explaining the changes required (including the one above)... just backup the database before making the changes. this would be a simple change for them to make, but i'd agree with Kian and not expect it any time soon. there's a 5-year old feature request to get tax rates changed from 2 to 3 decimal places (hardly a radical suggestion), it's got 45 votes and still nothing... if you want something doing with WHMCS, do it yourself... not the way it should be, just the way things are sadly.

not from the settings - it would need a hook or addon. there is an addon that would supposedly do it, Set Client Groups, but the developer has gone missing, support is non-existent and I don't think it's been updated for a while either... I wouldn't recommend buying it. as a hook, when product x has been purchased, you're looking at updating the tblclients table (which stores which group the client belongs to) - either with a db update query or by using the updateclient API...

sorry - i'm with you now.... got distracted by subdomains not working in v7.6 and assumed you were talking about the subdomains themselves rather than the SLD value. I don't think it would work because only the PID value would be passed with a bundle redirection, everything else would be dropped.

preselection in what sense ? you're determining which subdomains are shown with the product and in which order by how the product is setup... if you want to ensure they only have one subdomain option, just use one subdomain option in the product used with the bundle.

I suppose the usual horrible WHMCS solution would be to duplicate the product, hide it, change the subdomain order list to put your default subdomain first, and then use that product in the bundle.

I don't think it would be - I guess the logic would be with a direct product, WHMCS knows which product you're talking about; whereas with a bundle, it wouldn't (I assume even if there was only one product in the bundle). I can't think of an obvious simple workaround - though that isn't helped by subdomains not seeming to work in v7.6b1... unless i'm missing something.