Jump to content


Popular Content

Showing most liked content since 12/11/2017 in all areas

  1. 3 points
    As a continuation and update to the discussion at WHMCS.community, I'm pleased to announce that support for PHP 7.1 and PHP 7.2 is right around the corner! Your automatic update to WHMCS v7.5 will support PHP 5.6, 7.0, 7.1, and 7.2 environments with IonCube loader 10.1. To accomplish this WHMCS is leveraging yet-to-be released IonCube functionality that overcomes the lack of multi-PHP support in the IonCube Encoder. We expect to release WHMCS 7.5 in the first quarter of 2018.WHMCS v7.4.2 is scheduled for release in January 2018. Beyond general maintenance, this release will contain additional checks and notifications to enable the safest automatic update process. These checks will include new functionality to ensure your environment has the appropriate ionCube loaders before a new version of WHMCS is deployed, ensuring that your system is ready to run the new version of WHMCS without issue. As a result, only v7.4.2 (and future v7.4 releases) will be able to automatically update to WHMCS v7.5. Any WHMCS installation prior to V7.4.2 will need to first auto-update to 7.4.2, and only then, will you be able to update to v7.5 when that update becomes available.Supporting the latest versions of PHP is important to us and to you. Long before IonCube released their initial loaders and encoder with PHP 7.1 support, we had been testing WHMCS under PHP 7.1 internally and making sure our product was compatible. In September when IonCube first released their Encoder and Loader products with support for PHP 7.1, we quickly realized there were differences with how previous encoder / loaders work and these differences caused challenges to the automated upgrade process we strive to provide within WHMCS. Specifically files that were encoded for PHP 5.6 and 7.0 could not be read in PHP 7.1; while files encoded for PHP 7.1 could not be read in earlier versions. Despite the WHMCS codebase being PHP 7.1 ready, the tooling and target environments weren't.This would have prevented us from providing the seamless automatic experience we have so far delivered within the WHMCS 7 series. We made the choice not to release multiple builds that might confuse customers and wouldn't work with our automatic updater and instead we began investigating and prototyping ways to provide the most seamless end user experience to bridge the gap, and have been developing and evaluating a number of possible solutions. At the same time we contacted IonCube and they agreed an alternative solution would be preferable. However, they couldn't provide a firm commitment on if or when any changes could be expected. So, we had to explore more complex alternatives, ones that would deliver the environment support and the quality experience you expect from us. These prototypes ranged from a version of WHMCS with double encodings and proxy entry points to complex update mirrors and environment logic to alternating version schemas for different encodings.Last week IonCube contacted us with a beta edition of Encoder and Loader 10.1. Using these products, multiple PHP environment support can be achieved with far less complexity in WHMCS, our build systems, and our update infrastructure. We've already used it to produce alpha builds of WHMCS 7.5, validated those builds running on PHP 7.1 with the beta loaders and are confident it will allow us to provide a viable solution for all WHMCS customers.This bundled encoding is a welcome solution because it not only works for WHMCS, but for the whole PHP community. It reduces the efforts required to maintain up to date environments and software with the least impact on production systems. The downside is the IonCube Loader v10.1 is required.In an effort to mitigate this downside, we've had ongoing discussions with our partner cPanel. They are ready to move quickly and prioritize providing the new 10.1.0 loaders via EasyApache 4 as soon as IonCube releases them for general availability.Some customers have asked us about PHP's release cycle and a resulting warning displayed in the WHMCS System Health Status report. The intent of this systematic warning is to encourage planning for environment maintenance. Since PHP 7.0 will be receiving security patches up to December 2018 you should have adequate time to update both your environment and WHMCS.WHMCS v7.4.2 will be out next month. With that release and the IonCube Loader 10.1 expected shortly, you'll be all set for WHMCS v7.5. Stay tuned to the blog for more v7.5 feature announcements and release news!
  2. 2 points
    Hello, We have posted a further update on our blog and over in the news and announcements forum - Nate
  3. 1 point
    just for the avoidance of doubt, you're not using the original "Comparison" template are you ?? that got deprecated 2 years ago in v6.1 and is no longer updated/shipped - i'm going to assume you're using one of it's three replacements (Premium, Pure or Supreme), because it sounds as though you're describing the later stages of Standard_Cart. it sets the VAT rate and assigns the country/state details to checkout... no it's not - it is the country/state chosen at checkout that determines the VAT rate used in the invoice... I just doubled checked this twice, first by setting to Germany (19%) in the estimate tax settings, but changing it to Italy (22%) at checkout - the invoice used Italy and charged 22% VAT... then I ordered again, set it to Italy @ viewcart (22%), but changed it to Iraq at checkout (no VAT) and the invoice correctly contains no tax. the tab is irrelevant - what they put in checkout is the important detail... and if users want to commit tax fraud by saying they're in Iraq or wherever, then they can do it at checkout - though hopefully any fraud/geolocation methods you have in place should catch them doing that. I will add that, during the Iraq test order at checkout, it did say that the Total Due Today was £60.99 - this would have been the amount due if they had been in Italy, so that amount didn't visually change after selecting a different country (Iraq) - the invoice amount is £49.99 - you could say that was a bug (though not by WHMCS own definition), but it's a design flaw... btw - i'm not arguing that the cart templates are great, they're really not and the whole cart process hasn't significantly changed in years... just that i'm not seeing the issue you're seeing. It is - though bear in mind that WHMCS can assume the customer is in the default country (from general settings -> localisation) until they either login, or select another country at checkout... so if you're default country is UK, and the products are taxable, then it would show VAT at 20% (assuming you've added a tax rate for UK)... this might change depending on whether you have the EU VAT addon enabled. all the variables should be available in the ordersummary template if you want to remove tax being shown. that's just deleting the <div role="tabpanel" class="tab-pane" id="calcTaxes"> block of code in the viewcart template... you could in theory use a Language Override to blank out {$LANG.orderForm.estimateTaxes}, but that wouldn't actually remove the tab, just visually seems to... but it's still there. as previously status, that's just a tweak to ordersummary.tpl you can sort of already do that, but not in a simple way - and certainly not one that would be obvious to any user. if we go back to my original test order (Germany -> Italy), and to make things simpler, let's say the product is £10.... so setting the country to Germany in Estimate Taxes, sets the amount due to £11.90.... go forward to checkout, change the country to Italy and that amount doesn't change (but in fairness it's not designed to). but press the "Complete Order" button (with the ToS checkbox unticked or any required field not completed) and it recalculates the total using the updated VAT rate and refreshes the page.... and you'll get the usual error message about which fields have not yet been completed. so maybe you just need to redesign/reorder the checkout template, put a "Update Tax" button close to the country field and either hope by that stage they haven't completed the rest of the form, or find a workaround to that... untested, but it should work. the workflow is the workflow... it's not fit for purpose, but never really has been... hopefully v8 might change that, but that's many months away from even reaching beta. again, a tweak to viewcart.tpl - but is the second part necessary??... remove it by all means and let them choose a country at checkout...but I don't really think that ET is as much of an issue as you think it is - this is the first thread I can recall about it since the new templates were launched a couple of years ago. the splitting of estimate taxes out of the tabs has also been done in some commercially available orderform templates, such as Control. btw - we all know (but not WHMCS!) that "Bournemouth" is not a state/county of the UK... I don't even think it's a city, yet it's on the Counties list... I thought you might appreciate the irony given your other post... it's not technically difficult to do, just replacing tabs with 2 divs. if you don't do 1) then 2) becomes irrelevant... though i'm tempted to think that the quick fix would be more hassle to do than the preferred solution. then you should have tested first on a dev, or played with the Softaculous WHMCS Demo.
  4. 1 point
    scheduled no - but you could manually send one, with specific criteria (products, clients etc) using Mass Mail. I suspect the only scheduled method, unless there's an existing third-party addon that does this (i'm not aware of one), would be to write an action hook that would send the email on that date when the cronjob runs.
  5. 1 point
    perhaps the video below might help... https://youtu.be/PhEJegPBN9o once you have your server groups setup (with A in one, and B in the other), then the step you might be missing out is assigning each product to a particular server group (via the Modules tab in product setup).
  6. 1 point
    the lesson, of course, is always to test using a development installation before upgrading and read the changelogs! so there were preparatory cart template changes back in v7.2 and its removal from checkout occurred in v7.3b back in August 2017. it would be simple enough for them to put it back in a future update... it's whether they want to... and what the reason was for removing it in the first place (apart from the obvious one I mentioned previously) and whether that still applies.
  7. 1 point
    Welcome to WHMCS.Community AL ZAHRA! We're glad you're here please take some time to familiarise yourself with the Community Rules & Guidelines and take a moment to introduce yourself to other WHMCS.Community members in the Introduce Yourself Board.
  8. 1 point
    to test this, i've just enabled PayPal Express in a v7.4.1 dev (using Standard Cart) and you are partially correct - by the time you get to checkout, PayPal Express is not an option... however, on the page before checkout, viewcart, there is a new Paypal button... there was a template change in one of the v7.2 releases that added a gateway array option to viewcart... so the question is - are you using the latest version of Standard_cart, or if using a custom orderform template, have you updated it since v7.2 was released?
  9. 1 point
    i'm assuming you're referring to... then to do it on the server page should only require a similar hook (at least with regards to the db query), and use ClientAreaPageServerStatus instead of ClientAreaPageHome... <?php use Illuminate\Database\Capsule\Manager as Capsule; function serverstatus_network_issues_hook($vars) { $client = Menu::context('client'); $networkissues = Capsule::table('tblnetworkissues') ->join('tblhosting', 'tblnetworkissues.server', '=', 'tblhosting.server') ->leftjoin('tblservers','tblnetworkissues.server', '=', 'tblservers.id') ->select('tblnetworkissues.*','tblservers.name as server') ->where('tblhosting.userid', $client->id) ->where('tblnetworkissues.status','<>','Resolved') ->where('tblnetworkissues.type','Server') ->orderby('tblnetworkissues.lastupdate','desc') ->groupby('tblnetworkissues.id') ->take(2) ->get(); $encodedata = json_encode($networkissues); $decodedata = json_decode($encodedata, true); return array("issues" => $decodedata); } add_hook("ClientAreaPageServerStatus", 1, "serverstatus_network_issues_hook"); ?> I can see an issue with date formats, but you could fix that in the hook, or in the template using Smarty... other than that, the above hook looks fine to me.
  10. 1 point
    there used to be a Product Limiter module, now free, that limits the quantity of any product a user can have... https://docs.jetapps.com/whmcs-product-limiter-about though bear in mind that it's no longer being updated and I haven't tested it with v7 - so if you have a dev installation, you could test it with that to see if it does what you want. there's also ModulesGarden's Discount Center module, which may be an alternate paid path to using promotion codes.
  11. 1 point
    Welcome to WHMCS.Community Mark van Dooren! We're glad you're here please take some time to familiarise yourself with the Community Rules & Guidelines and take a moment to introduce yourself to other WHMCS.Community members in the Introduce Yourself Board.
  12. 1 point
    it does indeed... though I doubt you need the template variable assigned in that way... if for no other reason than you're not using it! the only time it would be of use would be if you were minimising the sidebar on a specific template page, and even then you'd probably use templatefile instead.
  13. 1 point
    @dani88 if it helps, this worked for me... <?php add_hook('ClientAreaHeadOutput', 1, function($vars) { $template = $vars['template']; return <<<HTML <script> jQuery(function(){ jQuery('div[menuItemName="Categories"]').find('i[class~="fa-chevron-up"]').click(); }); </script> HTML; });
  14. 1 point
    don't let it beat you, Jeff... there will be more bumpy issues down the road using WHMCS than this!! I don't think Andrew's code worked in the thread below... though I can't recall trying it personally. modifying the template would be the way to go with this... so in standard_cart/configureproduct.tpl, this... <div class="pull-md-right col-md-9"> <div class="header-lined"> <h1>{$LANG.orderconfigure}</h1> </div> </div> <div class="col-md-3 pull-md-left sidebar hidden-xs hidden-sm"> {include file="orderforms/standard_cart/sidebar-categories.tpl"} </div> <div class="col-md-9 pull-md-right"> becomes... <div class="pull-md-right col-md-{if $configurableoptions}12{else}9{/if}"> <div class="header-lined"> <h1>{$LANG.orderconfigure}</h1> </div> </div> {if !$configurableoptions} <div class="col-md-3 pull-md-left sidebar hidden-xs hidden-sm"> {include file="orderforms/standard_cart/sidebar-categories.tpl"} </div> {/if} <div class="col-md-{if $configurableoptions}12{else}9{/if} pull-md-right"> and if a product has configurable options, it doesn't load the sidebar (so no need for a hook), and auto adjusts the width of the page... sidebars gone. Jeff less stressed. problem solved.
  15. 1 point
    I don't think there is one... removing the sidebars via a hook is simple enough... but the template isn't designed to adjust full width if the sidebars aren't there... I suspect you're looking at customising configureproduct.tpl and changing the <div> widths 3/9 based on whether {$configurableoptions} exists.
  16. 1 point
    quickly tested on v7.4, but can see no reason why it wouldn't work on v7.2... <?php # Modify Recent News Links Hook # Written by brian! use WHMCS\View\Menu\Item; add_hook('ClientAreaHomepagePanels', 1, function(Item $homePagePanels) { $recentnews = $homePagePanels->getChild("Recent News"); if (empty($recentnews)) { return; } $recentchildren = $recentnews->getChildren(); foreach($recentchildren as $key => $child) { $recentnews->getChild($key) ->setURI('announcements.php'); } });
  17. 1 point
    Kia Ora Everyone, Welcome to the November 2017 Community Wrap-Up. WHMCS.Community November 2017 Statistics at a glance: 282 new members joined WHMCS.Community 356 new topics where created 1,071 posts were written in November WHMCS.Community Leaderboard Congratulations to our leaderboard winners this month @brian! in first place on 32 reputation points, @zomex & @sentq both tied on 5 points. Remember giving and receiving reactions might see you on our leaderboard next month! WHMCS.Community Top Picks This month we've made the transition to using Reactions to choose our Top Picks for the month, like the leaderboard this is all powered by the use of Reactions WHMCS V7.4 Launches! We were excited to launch WHMCS 7.4 in November. Head over to https://www.whmcs.com/whats-new/ to learn more about the new features headlined by our new Notifications Centre featuring an integration with Slack & HipChat as well as Credit Checkout Options & Ticket Collision Detection That's all folks! And that's the November Wrap-Up! Thanks for reading and remember we'd love your feedback on the wrap-ups and WHMCS.Community in general! We'll see you in January 2018!
  18. 1 point
    Welcome to WHMCS.Community nodored! We're glad you're here please take some time to familiarise yourself with the Community Rules & Guidelines and take a moment to introduce yourself to other WHMCS.Community members in the Introduce Yourself Board.
  19. 1 point
    Hi Chris, it is and it isn't. or perhaps on mine... let me explain what i'm thinking - these more recent templates (Premium/Pure/Supreme Comparison and Cloud/Universal Slider) basically just contain the opening page (products.tpl) - after that for configuring domains, products, viewcart, checkout etc, they all fall back to using Standard_Cart... as far as Stripe is concerned, logically (not that you should ever rely on that with WHMCS!), I think the only page that matters is checkout.tpl as that's the one that will link to the payment gateway... I don't see why the gateway would care what template was being used before getting to the checkout stage. now if you set a product group to use Pure Comparison (or any of the others above), or set it as a default orderform template, by the time you get to checkout it will be using Standard_cart (i've just double checked this to make sure) - so in my eyes, Stripe should work. the issue is that the documentation only tells you what it's incompatible with, namely the two old templates Boxes & Modern - and we know it works with SC... so it's a case of whether it needs to be SC at all stages, or only at the checkout stage... it would be quite a bizarre decision of WHMCS if it doesn't work for the above templates too. I can recall the thread below, but it never got a conclusion... but Feb 2017 was just after Stripe was introduced and I can remember it being a little buggy going by the complaints on here... i'd perhaps hold on and wait for one of the WHMCS guys/gals to confirm this either way.
  20. 1 point
    only standard_cart, and I guess by implication, the newer sliders and comparison orderform templates (as they'll use SC by the time you get to checkout). https://requests.whmcs.com/topic/have-both-modern-and-boxes-order-forms-support-stripe from @WHMCS John two months ago... https://docs.whmcs.com/Standard_Order_Form_Templates#Depreciated_Order_Form_Templates which is a polite way of saying that while they're still being shipped with new versions, they're not being updated... so if they still work, fine... if not, WHMCS are not necessarily going to fix it... in development terms, they're dead. I can't recall seeing a thread stating that they have... that possibility may depend on whether the Stripe module is internally coded to only work on SC... I don't know if that's the case, or whether it just needs a specific file(s) that are designated in the SC code, but missing from the others...
  21. 1 point
    Welcome to WHMCS.Community DATA1! We're glad you're here please take some time to familiarise yourself with the Community Rules & Guidelines and take a moment to introduce yourself to other WHMCS.Community members in the Introduce Yourself Board.
  22. 1 point
    There isn't anything in the code that would load the bar closed. You could use a hook to insert some javascript to "click" the chevron on load. Untested, but something like this: jQuery('div[menuItemName="Support Knowledgebase Tag Cloud"]').find('i[class~="fa-chevron-up"]').click(); As for the hook, http://developers.whmcs.com/hooks-reference/output/#clientareaheadoutput
  23. 1 point
    I asked the same question of the developers during the beta period - but never got an answer! however, if you modify domainregister.tpl and change... jQuery('.tld-filters a:first-child').click(); to... jQuery('.tld-filters a:*').click(); ... then all TLDs should be shown by default.
  24. 1 point
    Si no usas el ingles, eliminalo.
  25. 0 points
    if there isn't an existing product in Marketplace, then you should consider posting in Service Offers & Requests and paying a developer to create a custom solution for you.

Important Information

By using this site, you agree to our Terms of Use & Guidelines