jas8522

We had this issue as well. I *think* resolving this on our end was a combination of: - Clearing compiled template cache in templates_c folder - Cleraing browser cache However, I had also updated all templates with changes from github somewhere in the mix, so it's possible that played a part. It doesn't look like the captcha.tpl file had changed between releases, so if it's not the above two things that did it, then it must have been updating to most recent javascript... it'd be the only thing that makes any sense!

And this has worked for you when using a server module attached to a product addon? I ask because I'm doing it in this manner now and it only ever redirects me to the productdetails page without loading my custom template. I suspect that since the addon doesn't represent the entire product, it doesn't have the capability to override the template.

Oh weird. I see. So the WHMCS\View|Formatter\Price Object, when actually output on screen simply becomes the actual value. Strange that they couldn't simply have it show the value in the {debug} output, no? Since that's what it actually ends up being on screen. Then there wouldn't be any documentation needed; it would work as it always has. It works, but it's a bit sketchy in that I had no way of showing the cycle properly. I would have been able to do that if we could be guaranteed that each addon would have cycle pricing to match every single cycle of the parent product (then we could just borrow the cycle text from the parent product). But as it stands now, if you've got only monthly and annual pricing for the addon, but select biennial for the parent product, the addon goes to the lowest possible cycle -- monthly in this instance. The price is pulled via ajax query to the cart, but in the cart it doesn't show the cycle next to the addon, so I can't pull that data. So what happens is, the addon pricing is updated, but the cycle is removed from it. /** Addon Pricing Fixes **/ function ws_update_addon_cycle_pricing(){ var $billingcycle = jQuery('#inputBillingcycle').find(":selected").val(); jQuery(".addon-products .panel-addon").each( function(){ var $addon_title = jQuery(this).find('label').text(); var $addon_inputname = jQuery(this).find('label input').attr('name'); var $addon_price = jQuery(this).find('.panel-price'); if ($addon_price.text().indexOf('One Time') === -1){ //not one-time cycle var cycle_matched_price = jQuery.post("cart.php", { ajax: 1, a: 'confproduct', calctotal: true, configure: true, i: 0, billingcycle: $billingcycle, [$addon_inputname]: 'on', }).done(function(html) { jQuery(html).find('.pull-left').each(function(){ if ( jQuery(this).text().indexOf($addon_title.trim()) > -1 ){ $addon_price.text(jQuery(this).siblings('.pull-right').text()); } }); }); } }); } //triggers jQuery(document).ready(function(){ ws_update_addon_cycle_pricing(); jQuery('#inputBillingcycle').change(function(){ ws_update_addon_cycle_pricing(); }); });

Thanks! I just don't have any faith in their bug reporting management any longer. Recently, every time I report a bug they claim it's a feature request and that I must have it vie for attention at requests.whmcs.com, when it's a fairly obscure or technical bug and likely not going to get votes. Yet it's also super simple to fix, in most cases, like this one. We'll see if I can gather the time to report this properly only to be let down by their response again.

That's great, thanks so much! Is there documenation on working with these objects in templates? I couldn't seem to find it! For example, without the {debug} output showing me the structure of the object, how did you know this was the right object var? Guesswork? Output to screen until you find it? {$addoncycle.price} I did get some javascript in place to auto change the price, so now that you've shown me how to use the pricing object in my template, I can use this to create a dropdown.

Maybe you have some insight on this. My {debug} on the template shows that it *thinks* it has the prices, but intead of actually having the prices, it's got some kind of internal WHMCS pricing object... but if it really was in object format wouldn't the {debug} output show the data? It does for all other objects... in other words, I think they tried to introduce the pricing into the template vars, but messed up by providing the data in the wrong format. Though I could be interpreting that wrong!

As described on Wikipedia here, YK is not the official two char representation for the Yukon Territory; it's YT. Plesk's API validates Canadian provinces against their official two char representations and therefore responds with this and fails to provision because of this incorrect state value: <?xml version="1.0" encoding="UTF-8"?> <packet version="1.6.6.0"><customer><add><result><status>error</status><errcode>1023</errcode><errtext>cObject::update() failed: Some fields are empty or contain an improper value. ('state' = 'YK') Errors : state</errtext></result></add></customer></packet> WHMCS should change their two char storage from YK to YT to fix this.

In a recent WHMCS update we were provided with the ability to enter different pricing cycles for product addons. This is great! However it as resulted in the standard cart orderform not behaving well. Steps to reproduce: Configure a product with annual pricing only. Configure its addon to both have Monthly and Annual pricing Place an order with the standard cart orderform with the product set to annual pricing. When configuring the product, the addon will show its monthly pricing, yet when you add the addon to the cart, it will show annual pricing (bait and switch!) At bare minimum, the order form should dynamically change the display of the addon pricing (on the addon itself; where the title and description is) based on the parent product's selected cycle. Optimally I would much prefer that the addon have a selectable drop down so that the buyer can choose a different payment cycle for their addon than the parent product, but that it would default to matching the cycle with the parent product.

Curious to see if anyone else has tried using the new provisioning module capabilities associated with a product addon (not a product). The standard provisioning actions like create/terminate are working just fine. But I'm trying to create a button that opens a custom page with a custom page template and I can't seem to get the code right -- it always just loads the product's page rather than my custom page. Here's the relevant code: function module_domainreports(array $params){ return array( 'pagetitle' => 'Domain Reports', 'templatefile' => 'domainreports', 'vars' => array( 'test1' => 'hello', 'test2' => 'world', ), ); } function module_ClientAreaAllowedFunctions() { return array( "Domain Reports" => "domainreports", ); } function module_ClientArea(array $params) { return ' <form method="get" action="clientarea.php"> <input type="hidden" name="action" value="productdetails" /> <input type="hidden" name="id" value="' . $params['serviceid'] . '" /> <input type="hidden" name="modop" value="custom" /> <input type="hidden" name="a" value="domainreports" /> <button type="submit">View Reports</button> </form>'; } I do have a domainreports.tpl file in my module dir. It's got a single line of text in it. Am I simply doing it wrong?

Nope. I asked WHMCS in a ticket, because I wanted to allow things like "resubmit domain transfer" when the domain is in "Pending Transfer" status. No such luck. They said to createa feature request at requests.whmcs.com ... but we all know it's going to get buried there as non-techy WHMCS users want their frivolous features that any dev could implement without WHMCS's help.

Awesome, thanks for the hook!

On multiple occasions now I've set a date for override auto-suspend and managed to miss checking the box beside it. While this is obviously user error, it's not the first time it has happened and unfortunately results in some serious problems where client's systems are auto-suspended because of my negligence. I think that to prevent this, the checkbox should auto-check when you click in the date field to select a date.

Huh, indeed. The other template I was working with did have those kinds of conditional checks. But that doesn't explain why this one didn't work. I've got URLs within the conditionals of my final (working) template as well and no issues now. Color me stumped.

Support set me straight. My variable checking model was the problem. We should not be using {if $variable} to check if it exists or is not empty. As suggested by WHMCS staff, we should instead be using {if isset($variable)} or this worked fine for me as well: {if !empty($variable)} Once I switched up the conditionals to check variables in that manner, all syntax errors stopped.

Fixed up the $invoice_payment_method variable and tried swapping quotes for single quotes. All of my quotes applied to URLs were changed back to double quotes upon save. But I was able to change all my conditional comparison strings to single quotes and have them stay that way. Sadly it didn't make a difference. As @brian! hinted at, once I removed all links from within my conditional text, the syntax error stopped showing up in the logs. I'm going to submit this as a bug.