Jump to content

startover909

Members
  • Content count

    23
  • Joined

  • Last visited

Community Reputation

0 Neutral

About startover909

  • Rank
    Junior Member
  1. This is a showcase of a non-hosting WHMCS custom integration for my small business IT service and consulting company based in Houston, TX. Main site: https://www.felinepc.com Client portal: https://secure.felinepc.com When I started looking into building a client portal to streamline client management, billing and support for my IT service clients, it soon became evident to me that most of the existing products and solutions on the market simply do not meet my standards. The idea of using WHMCS for my project stems from my years of experience as a customer with various hosting providers since the early 2000's. I knew exactly what WHMCS looked like inside and out. I understood that it would take a lot of work to customize all the templates, hooks and wordings to achieve what I wanted, and that it may inevitably require some wrestling and compromises. But ultimately I decided to go with WHMCS and I'm overall very satisfied with the final product. It was definitely not a very easy task: it's only when you dig deep into the details that you realize hosting is after all what WHMCS lives and breathes. The references and layouts are everywhere. In the end, about 30 template TPL's were modified (mostly related to the pages after customer logs in), another 20 or so email templates as well. Over 100 lines of language overrides. Lots of hooks to customize the menus/titles etc and lots of CSS styling overrides (I have to say WHMCS's built-in CSS codes are quite a mess). If others want to implement WHMCS for non-hosting businesses, please feel free to get in touch with me and I'd be happy to provide some insights.
  2. While you're at checkout.tpl (of course, you should copy the original order form template to create your own template), I also recommend that you remove the {if $loggedin || $custtype eq "existing"} class="hidden"{/if} logic from the sign up container <div id="containerNewUserSignup"{if $loggedin || $custtype eq "existing"} class="hidden"{/if}> This way, the users will see their pre-filled info with fields that are set to read-only (already by template) so they get to review their info before submitting the order. This gives them a chance to update their old info which can result in CC declines etc. You may also want to add a little if logic to the "Please enter your personal details and billing information to checkout" heading to make it show something like "If you need to update your billing information, please click here, then return to checkout by clicking "Cart" on the navigatio menu" for logged in users <p>{if !$loggedin}{$LANG.orderForm.enterPersonalDetails}{else}If you need to update your billing information, please <a href="/yourwhmcs/clientarea.php?action=details">click here</a>, then return to checkout by clicking "Cart" on the navigation menu.{/if}</p> Now that is more like a "standard" shopping cart.
  3. I achieved this myself by creating a basic custom WHMCS page, loginredirectcheckout.php, that has "require login" enabled. <?php use WHMCS\ClientArea; define("CLIENTAREA",true); require __DIR__ . '/init.php'; $ca = new ClientArea(); $ca->initPage(); $ca->requireLogin(); $ca->setTemplate('loginredirectcheckout'); $ca->output(); ?> Then on the corresponding loginredirectcheckout.tpl file, I simply added one line of javascript code to redirect to the checkout page. <script> window.location = 'https://yourwhmcs/cart.php?a=checkout'; </script> Then I edited the checkout.tpl template, replaced the existing "already registered" and "register" buttons with a link to the loginredirect.php file (apply btn and btn-info classes to the anchor to make it look just like the original button): <a href="/yourwhmcs/loginredirectcheckout.php" class="btn btn-info{if $loggedin} hidden{/if}">{$LANG.orderForm.alreadyRegistered}</a> Upon clicking, the user will be required to login, then once logged in, redirected right back to the checkout page. Now credit card info pre-filled. No more confusions etc. Hopefully this will help others who want their order form to behave like this.
  4. Due date on a new order

    Just to be clear, when using this feature, the orders that are placed with a credit card are still charged instantly, not delayed for X days, correct? I did one test order and it seemed to be the case. Just don't want any surprises.
  5. I use the Stripe gateway and standard cart. When the user clicks the "Complete Order" button to submit an order, the mouse cursor changes to the "not-allowed" state during payment processing which is the stop sign looking icon. I find this cursor very ugly and unnecessary, because the button is already greyed out once it's clicked to avoid the risk of double submission. During peak hours it is not unusual for a gateway like Stripe to be somewhat slow, so the user often has to stare at that cursor for 3-4 seconds or even more. I don't know if it's Bootstrap, jquery js or stripe.js that changes the button on order submission, but how do I change this behavior? Either make it just the regular cursor or something like the waiting cursor. Thanks!
  6. Never mind, all the data table lists (invoice list etc) inside the client area broke. Was worth a try though! Really wish WHMCS could optimize their code to defer loading of js and css, especially now that they have down to only few scripts . I also noticed that on some pages like the table lists WHMCS places several additional js and css in the middle of <body> (not a good practice). Maybe those depended on the main .js in the HEAD.
  7. I'm on WHMCS 7.5.1. I noticed that the site places a single, minified js file, scripts.min.js, in its header: <script type="text/javascript"> var csrfToken = '{$token}', markdownGuide = '{lang key="markdown.title"}', locale = '{if !empty($mdeLocale)}{$mdeLocale}{else}en{/if}', saved = '{lang key="markdown.saved"}', saving = '{lang key="markdown.saving"}', whmcsBaseUrl = "{\WHMCS\Utility\Environment\WebHelper::getBaseUrl()}"; </script> <script src="{$WEB_ROOT}/templates/{$template}/js/scripts.min.js?v={$versionHash}"></script> I'm just wondering if it's safe to move this section to the footer so it does not "render block"? Just tried it on a site under development and seems fine so far at first glance. I wonder if others did the same and if this can potentially cause some issues for WHMCS. Thanks.
  8. I'm currently in the process of setting up WHMCS (7.5.1) along with a main site on a pretty much empty dedicated server (decent E3 with SSD). The site does not run "slow" by any means. It loads in about 650ms to 800ms on Pingdom and GTMetrix tests. What I did find curious is that it is exactly and consistently around 200ms slower TTFB compared to the same sites on the same server, mostly running Wordpress. All running the same PHP and MySQL and over SSL (so all the overheads are accounted for). So while the other site would have a TTFB of say 250ms to a given test server (including SSL handshake), WHMCS would take about 450ms, pushing it just a bit over the most "ideal" ballpark. This can be also easily verified by using Chrome's developer tool - network tool. Is this 200ms due to the IonCube encoding, or is the speed of the application itself just what it is? Does this number seem right to you? If you have any other PHP/MySQL site especially Wordpress running along side WHMCS on the exact same server, and not utilizing CDN's such as cloudflare that can skew the results, do you mind doing a test and see if your WHMCS is also consistently a bit slower TTFB (test during idle times)? Thanks.
  9. I just realized WHMCS apparently does not have any concept on the proper design for text-heavy pages. This community itself is full blown full-width on all pages and posts...
  10. Using the Six theme. WHMCS defaults to Bootstrap's max 1170px main container width on all pages that do not have a side bar. 1170px is way too wide for pages such as announcements and ticket forms (the readability of a heavy text page suffers once a paragraph exceeds a certain width, generally around 800px). So on all these pages, WHMCS wraps them in a full-width Bootstrap container with the class "col-xs-12 main-content". It would be so much easier if it adds an additional class to identify the page, such as "home-page", "submit-ticket", "announcements" etc like all Wordpress pages do, so we can style them directly in CSS via "max-width" and "margin:auto" as needed. But WHMCS doesn't do this, and I can't find the actual "col-xs-12 main-content" container in the .TPL template files (the contents in the templates start AFTER the main container). So how do I efficiently limit the width of these pages? I can use CSS to limit the width of the main element of the page, such as the ticket form, the article containers etc . The problem is that the "header-lined" class container which includes the main heading of the page and the breadcrumbs sit outside the page's contents, right under the "col-xs-12 main-content" container. Again these "header-lined" containers do not have any page identification class added. So these will remain left aligned if we center align the narrowed-down content container on the page. Your advice would be greatly appreciated.
  11. Anyone else finds the "Already Registered?" button behavior on the checkout page flawed? Clicking it triggers JS that simply shows the login username/password boxes without actually letting the user login. So the login is performed at the same time as order submission. The idea is that less clicking and not leaving the checkout page is a good thing. Except that: 1. Without actually logging in, the user has to enter the credit card manually instead of using the one on file. This defeats one of the most important benefits of being "registered". 2. If the user enters a credit that is different from the one he has on file, his card on file gets updated without even his knowledge, as no where on the order page suggests that. 3. If the user made a typo on the password, he does not seem to even get a password incorrect error message, possibly causing confusion Shouldn't the better approach be what every other online store does: clicking "Already Registered" button actually leads user to login page, then redirects back to the checkout page upon successful login? Anyone has any idea how to achieve this (the button it self can be edited ini the template I assume, but what about the redirect part?) Thanks.
  12. Found the issue: the TOS must be set under General Settings -> Ordering -> Terms of Service URL for this to work properly (otherwise clicking the TOS links back to the quote itself and quote can be accepted without checking the checkbox). With the TOS option enabled and link URL set, then the URL on the acceptance form links correctly and not checking the box will result in error.
  13. Update: tried to use SMTP instead of PHP Mail and problem went away.
  14. I'm on 7.5.1. Today I just found a potential bug: whenever a client's company name contains a comma, such as ABC Company, Inc., any mail sent to the client will fail with error "Could not instantiate mail function". I did not test with any other character or other fields. I'm using PHP Mail. Can others run a test by adding a mock client with a comma in company name and send a test welcome email to it and see if it results in this error? Thanks.
  15. Handle more formal signing and contracts with WHMCS

    Just a small bump. Anyone can share any ideas? Thanks.
×

Important Information

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