Leaderboard

Hi WHMCS ecosystem developers! I am excited to share an early heads-up about the upcoming WHMCS 9.0 release by the end of 2025 - a major update that brings important changes to the platform’s technical requirements. As part of this release, several core dependencies will be updated, and minimum system requirements will be increased. These changes are designed to improve performance, security, and compatibility with modern PHP standards. Key Updates in WHMCS 9.0: Minimum PHP version: 8.2 Recommended PHP version: 8.3 Minimum ionCube Loader version: 13.0.2 or higher Recommended ionCube Loader version: 14.4.0 or higher Updated dependencies: A number of underlying libraries and components have been upgraded. Some notable changes include: Smarty v3.1.48 —> v4.3.4 Legacy Smarty Tags are being deprecated and will no longer function in 9.0. Smarty Template Objects (including their use in plugins) will no longer be supported. guzzlehttp v7.4 —> v7.4.5 illuminate v7.x —> v9.0 I have attached a provisional list of dependency changes to this post. Please also use this thread to provide your feedback and ask questions of the Development Team regarding these requirement and dependency changes. These changes will require action from module developers to ensure continued compatibility. We recommend reviewing your module code and preparing for updates ahead of the release. We’ll be sharing more details, including a release window, definitive changelog and developer guidance, between now and the end of 2025 to help you get ready. Thank you for being a valued part of the WHMCS ecosystem. We appreciate your continued support and look forward to working together to make WHMCS 9.0 a successful release. whmcsv90_composerlock_provisional.txt

While I understand that bugs are part of any Release Candidate cycle, it's concerning that we are still discussing basic optimization issues like proper OPcache support. And let's not even get started on the fact that we still don't have 100% native Nginx support. This becomes particularly ironic with the introduction of the new WHMCS Cloud Solution. With cloud hosting, the resource costs are on their side, so you'd think they'd be rushing to support Nginx to reduce their own infrastructure expenses. It's like being sold a high-performance engine but being told you have to power it with hamster wheels. Maybe once their bills start rolling in, Nginx support will suddenly become a priority. This all points to the bigger issue: the development velocity. Core development feels like it's just about "keeping the lights on" (PHP/ionCube updates) rather than actual innovation. This stagnation has allowed third-party developers like ModulesGarden to build entire businesses by selling us functionality that should have been in the core a decade ago. When you look at the "Total Cost of Ownership" license fees + necessary third-party modules, the value proposition is slipping. Newer platforms like Upmind are entering the market with an API-first architecture and modern features built-in from day one. If WHMCS continues to outsource innovation to the community while raising prices for maintenance updates, that competitive threat is going to become an exodus very quickly. We need core features that match the modern hosting landscape, not just compatibility patches.

How WHMCS have set this as a RC instead of a Beta is insane. It's a huge upgrade in terms of it's impact on themes/modules. No beta, no reply from WHMCS, no forums specific to v9.

Okay, maybe I was too quick about credit notes. It seems a lot of the features are "coming soon™️". This is not a Release Candidate lol. This is not even alpha. This is internal development. Nothing can convince me that this release didn't just happen because WHMCS promised us a release in December.

@BENELUX, Today's the day!! https://blog.whmcs.com/133775/whmcs-90-release-candidate-out-now

This week or next! It sure would be nice to double the size of the engineering team temporarily for one release every few years!

@stormy, I'm glad to hear the e-invoicing feature will be a real value add for you. We are working with expert solution-providers in this space, so we're confident about delivering an easy to use and compliant solution with the broadest coverage. @andp97, Yes, by the end of the year in a pre-release version of WHMCS you will have access to this new feature. This bullet point actually describes two significant features which we're very excited about: 1. A RESTful API which provides access to the product catalogue and shopping cart logic. This will provide a suite of new endpoints to get product catalogue information, add, manipulate and get information about items in the cart (including price breakdowns and totals) and much more, all without touching the cart.php file or PHP session data. This means that power users could create their own highly-bespoke frontends whilst WHMCS handles the maths in the background, before seamlessly passing visitors to the checkout page to complete payment. 2. A brand new thin client powered by the aforementioned new API capabilities, providing a thoroughly modern purchase experience based on Vue.js. I've attached a sneak peak below. The new BuyFlow is a compiled Single-page application, meaning the layout isn't manipulated through templates, but you will be able to customise the colours to match your theme through a custom.css overrides file. The shopping cart as it exists today (cart.php and order form templates) isn't going away and will still be available if you'd like to stay with the familiar experience. Stay tuned to our blog and socials over the coming weeks for more information!

Hi @venkat.j, The current latest version is 8.13. This behaviour suggests the dates were set to 00/00/0000, either by an admin (in which case there should be an entry in the client's Log tab) or by a rogue after-market module (in which case there probably wouldn't). You can edit the date fields to set the actual dates and click Save Changes. The correct dates will be stored.

Hi all, In 8.13 a small improvement was made to the accounting of refunded mass-pay invoices. Prior to this the totals of mass-pay invoices were included in the overall income statistics, but now they are excluded as it's already accounted for by the original invoices.

But you did ask them, and not by just posting here? EDIT: This is a bit old now, but a fast search on this board found:

Hello @ThemeMetro This is a known issue, and we have published a HotFix. For more details, please review the following. Apologies for any inconvenience. Kind regards, Stephen.

Thanks to @Mytihost, I found an elegant solution for this issue. The following hook: add_hook('ClientAreaPage', 1, function($vars) { if (!empty($vars['clientsdetails']['customfields'])) { $customfieldsAssoc = []; foreach ($vars['clientsdetails']['customfields'] as $field) { $customfieldsAssoc[$field['id']] = $field['value']; } return ['customfieldsAssoc' => $customfieldsAssoc]; } }); makes available the value of any client custom field in a template, using i.e. the form {$customfieldsAssoc.17} (where "17" is the id field in the tbl customfields)

Hi @Jade D, I have responded to your ticket, but just wanted to follow up here so there's an answer if anybody else comes across this. The underlying issue here is that your web server was advertising a domain other than that registered for your license. This causes the license cache in your install to be invalid, and so your install needs to check in with our licensing infrastructure to validate your license. Since the details we held about your license were different to those being advertised by your web server, your install kept making a request to our licensing API. We rate limit all requests made to our licensing infrastructure to ensure stability thereof for all our customers. If your server sends too many requests, it will be temporarily blacklisted as part of this rate limit. To resolve this, make sure that your web server is only advertising the server_name that we have listed in your Valid Domains. Wait for 30 minutes or so and the rate limit will be removed, then your install will get a response back from the licensing servers that your license is valid and access will be restored. If anybody is unable to get to the bottom of this, please reach out to our support team and we can help!

You aren't authenticated in your hooks. The hooks aren't running as you - they're running as the system. WHMCS doesn't offer a native way of logging in as an admin in a hook. If you just want to download the invoice, you can include /includes/invoicefunctions.php and run the pdfInvoice($invoiceId) function.

I take it you weren't here when WHMCS yanked owned license update "support addons" and we all lost any updating of those convenient owned and now worthless licenses many of us bought? I had two.

I'm fuming. Is this yet another price increase, after the last not long ago?

Hello, Not at all and it's highly recommended, to change the admin path.

I am happy to say that the development cycle of vBLink 2.0 is now complete. The release was delayed for a complete ground-up rewrite after WHMCS 4 was announced. It is not ready for download just yet; I have not taken the time to create an installer or documentation because of two major issues that may become a factor in the long term success of vBLink. The first issue is vBulletin 4 support is not included. This is in part because of the fact that I do not agree with decision by vBulletin to change the licensing structure essentially us to purchase new licenses. I own three licenses, two for production sites, one for a development site. The cost to upgrade is going to be huge, especially if I choose the publishing suite. So at this point I have no access to vB4 code. The second issue is that from a business standpoint vBLink has not been a success, or at least the free/paid model that it has been distributed with. In the past year there have been over 400 downloads of vBLink but less than 2% were paid licenses making vB4 support hardly justifiable. So the question now is what to do next, and that is the reason that I am posting this message. Obviously, vBLink without vB4 support is only going to be useful for a short time until v4 goes gold. But without a solid community and financial backing behind it, I have no reason to continue development. But one promise I will make is that if I do walk away from vBLink, I will release all source code into the public domain; I do not believe in holding code hostage. If I do in fact release vBLink 2.0, I'm thinking of a 3-tier release structure... vBLink Basic (Free, Fully Encoded with only account bridging and no extras) vBLink Pro (Mid-range cost, a few admin module source files encoded, fully functional) vBLink Pro Dev (Highest cost, fully functional with full source) All feedback is welcome and will help determine the future of this vBulletin integration.

Your process sounds good apart from WHMCS. I would never recommend trying to import tables to new files. You need to update your existing install as normal. You can update from your version but you may have more luck doing a manual update. Backup everything, upload the new v8.13 files, adjust your hosting/server settings to meet the requirements (e.g you may need to update PHP) then run the installation script.

Yeah, except for adding AI to domain search, this release doesn't really provide on any of the other promises. Credit notes doesn't work either. When you cancel an invoice, WHMCS just adds a transaction to the invoice. If the invoice has a total of $100, WHMCS just adds a transaction of $100 and cancels the invoice. There's no credit note or anything.

Nexus is gonna disappoint you. It's just a reskinned Twenty One template (for the system template) and a reskinned Standard Cart template (for the cart template). It's only during checkout that it's different.

Hello, It's very easy to resolve with Hook, just do Create a hook file at: whmcs/includes/hooks/invoice-lineitem-date.php <?php use Illuminate\Database\Capsule\Manager as Capsule; use Carbon\Carbon; add_hook('InvoiceCreationPreEmail', 1, function ($vars) { $invoiceId = (int) $vars['invoiceid']; $inv = Capsule::table('tblinvoices')->where('id', $invoiceId)->first(); if (!$inv) { return; } $dateText = Carbon::parse($inv->date)->format('d-m-Y'); $items = Capsule::table('tblinvoiceitems') ->where('invoiceid', $invoiceId) ->get(); foreach ($items as $item) { $isBillableItem = ($item->type === 'Item'); if (!$isBillableItem) { continue; } $newDescription = $item->description; if (strpos($newDescription, '{DAY}') !== false || strpos($newDescription, '{MONTH}') !== false || strpos($newDescription, '{YEAR}') !== false) { $newDescription = preg_replace( '/\{DAY\}\s*-\s*\{MONTH\}\s*-\s*\{YEAR\}/i', $dateText, $newDescription ); } else { $newDescription .= " ({$dateText})"; } Capsule::table('tblinvoiceitems') ->where('id', $item->id) ->update(['description' => $newDescription]); } });

You put them in widgets. Then you have to go into admin roles and enable display for them, checkboxes at the bottom.

This is caused by misconfigured WHOIS servers. You need to ensure the correct string for "available". When dealing with this error, you can navigate to the WHOIS interface in WHMCS admin and check some WHOIS responses for domain that status is known For example, you can use "thisdomainisn0tregistered.org" as a test for getting the appropriate response of WHOIS for a domain that is available for registration. Then, you need to incorporate your findings in the whois.json file. Configuring the appropriate values in this manner will ensure that your clients are given the opportunity to register the domain which is "available" and configured for sale in your WHMCS. Example { "extensions": ".org", "uri": "socket://whois.publicinterestregistry.net", "available": "Domain not found." }

@bear is right in this case. AI is generally only a help if you already know what you're doing. @MytihostYou can't solve the issue using Javascript. Javascript is a client side language, so you can only use it to manipulate the data you already have received from the client. If you only want to get a set amount of records for each page, you could use the limit() and offset() methods on your collection. Unfortunately, WHMCS doesn't support the paginate() method provided by Laravel. If you're retrieving thousands of records from the database, it's going to be slower than retrieving 50.

Hi @ZeroMB, Thanks for that information. I've logged case #WHMCS-22693 with our developers in order to have this reviewed for future releases. Whilst I cannot provide an estimated time for completion for this, once we resolve cases and push features they are available at our change log, here: https://changelog.whmcs.com/ Thanks again for taking the time to report your findings.

We understand your frustration, and we’re sorry to hear about your experience. To clarify, the lifetime license you purchased grants you indefinite use of the theme, but as stated on our product page, ongoing updates and support require an active subscription. This is a common practice in the industry, as maintaining compatibility with WHMCS updates involves continuous development work, which incurs costs for us as well. We’d be happy to assist you further if you choose to renew your support & Updates plan. Alternatively, you’re welcome to continue using the existing version of the theme without updates. If you have any questions about your options, feel free to reach out. Thank you for your understanding.

Thank you mate, it needs to be developed more, it still has deficiencies, for this reason I shared it on github, let anyone who wants to develop it

@websavers Really grateful to you for such opensource contribution. I was looking for it and you just made it super easy for me. Again Thank you so much. ❤️

May be you are having spam user registration, You can simply enable captcha from setting and it will stop

No I think this is something other issue Can you check client create logs if possible post here

Hello @HarryAdney You can try from System Setting -> General Setting -> 1st Tab (General) -> Update "Records to Display per Page". You can update 200 records per page

I thank you for your nice comments. I uploaded it to GitHub so that anyone who wants to take it and develop and continue.

Sure, Thanks for the update. As you have added language option here, so it will be easy for all users to use it. Thanks

We have never autoclosed any tickets (they're reviewed every few days as they progress if not resolved). No place for automation, at least in our operation.

The native Stripe module is indeed great if you're only using Stripe for card payments. However, if you want to take advantage of the full range of payment methods Stripe supports—such as Alipay, Cash App, iDEAL, Revolut Pay, SEPA and many others—you'll need the RackNode Stripe Checkout Module.

Informative video with detailed explanation. Very helpful for beginners. Thanks!

Hello, Your website is looking nice. I just want to suggest, do minor changes in the services section to represent in a better way. Thanks

Generally not. Most of the time when it's about missing fixes vs paid marketplace stuff it's ignored, quietly removed, or John himself comes in here and tells us it's because we all asked for the thing they added. If not that we asked for it, it's "to help you serve your customers", and price increases are to "keep developing and stay financially sound" or some such. I'd suggest dev costs have not increased at nearly the same pace as the bottom line for sales has. Just my 2 cents, adjusted for inflation.

PayPal integration change removed the ability to block subscriptions, which in some cases(basically all) confuse customers as to why they are still paying for something resulting in more chargebacks and disputes. An outstanding issue with the API reported over a year ago is scheduled to "maybe" get fixed some time in 2025 after it has been an issue for more than 4 years. New things implemented only exposed to addons mean a great way for the secondary market to further extract money. In times of high inflation the very worst thing you can do is raise prices. Don't have to have a masters in economics to know that, it's simple math. For the longest time the auto update has failed and while that seems to no longer happen, there was a never a conclusion as to why. Source for older versions float around the net and the code isn't pretty, so unless half the system has been rewritten since 7.x some of that stuff is still in there. The only constant in this is that good feature requests are declined so beyond the investment itself you then have to find a third-party addon if you need something "specific" (that somehow hundreds of people voted for). I have seen no meaningful change since the last price increase. Every positive offset by a new negative. If "development" costs too much, try doing what we were all forced to do in this economy: Cut costs! Instead of nickle and diming the loyal customers that propped up the business the last 10 years. You know other places grandfather long term customers into cheaper plans instead of giving them the finger. (I tried posting here from my community account, but it won't even let me, wtf)

For anyone wanting to hide SiteJet from WHMCS here is the code I use, its a combination of a code earlier here provided by a user and addition to hide it inside the package <?php use WHMCS\View\Menu\Item as MenuItem; // Hide in Client Area Sidebar add_hook('ClientAreaPage', 1, function($vars) { $primarySidebar = Menu::primarySidebar(); if ($primarySidebar) { $serviceActions = $primarySidebar->getChild('Service Details Actions'); if ($serviceActions) { $serviceActions->removeChild('sitejet'); } } }); // Hide from Client area add_hook('ClientAreaFooterOutput', 1, function($vars) { return <<<STYLE <style> #sitejetPromoPanel{ display: none !important; } button[data-identifier="sitejet"], li[data-identifier="sitejet"]{ display:none !important; } button[data-identifier="sitejet"] + .btn-group > .btn[data-toggle="dropdown"]{ border-top-left-radius: 3.2px; border-bottom-left-radius: 3.2px; } button[data-identifier=“sitejet”] + .btn-group > .btn[data-toggle=“dropdown”], .btn-group:has(> button[data-identifier=“sitejet”]) > .btn[data-toggle=“dropdown”] { display: none !important; } </style> STYLE; }); // Adjust the Client Area display for Sitejet panel add_hook('ClientAreaFooterOutput', 1, function($vars) { return <<<SCRIPT <script> jQuery(document).ready(function($) { // Change the title text inside h3 $('#cPanelPackagePanel h3.panel-title.card-title').text("Package/Domain"); // Change col-sm-6 to col-md-3 for the image column $('#cPanelPackagePanel .col-sm-6').first().removeClass('col-sm-6').addClass('col-md-3'); // Remove the image with class card-img-top $('#cPanelPackagePanel img.card-img-top').remove(); }); </script> SCRIPT; }); This hook will do as stated earlier where the Promosplash on the frontpage of the SIX theme is showing the SiteJet, then the last code is inside the client area, it adjusts the "Package/Domain" which was always there and they changed to "SiteJet Panel" by adjusting that text back, then removing the half page, into a full 3 row page, and remove the image display so it looks like this See, I pay for the license, I don't see why there isn't a toggle switch to turn off your promotional advertisement but since that is not possible this HOOK legitimately does that, thanks to whomever wrote the first part for the splash on the main client page, but this one also edits the in client product page removing the webpros advertisement and makes it look like it did before. You can always edit that code to remove the image and or replace with yours but this will be enough for me, it keeps it clean. (The image above, Ive redacted any sensitive information but obviously it says the domain name above the Manage Domain). Thank you.

Me too. This * only exists that WHMCS can make money with it! - No e-invoicing - No Cancel Management for europe clients - Not enough Payment Gateways (Amazon-Pay, Klarna over Stripe etc ...) You release new versions that are nothing more than bug fix releases, there's nothing new anymore. Look at https://requests.whmcs.com/, the list is full of fantastic ideas ... I'm just disappointed! Not about the increase, no because there is simply nothing new. But you want money for nothing more and more.

Hello, If you are still looking for one I have custom made WHMCS Hyper-V Addon and Server Module

See here: https://github.com/hybula 😃

Have you tried MarketConnect? You can fully automate the reselling of hosted email, so the hosting part gets managed for you leaving the VPS hosting part untouched. The services on MarketConnect can be promoted automatically upon the purchase of other products on your website and/or within the client area. All seamleassy integrated within the WHMCS front-end: https://marketplace.whmcs.com/connect https://marketplace.whmcs.com/help/connect/kb/ox_app_suite

For many businesses, there will be keywords that you do not want customers to be able to use. For example, you might want to prevent them from being able to create services under any of your domain names, or prevent the use of strings like "admin" or "root" in the "First Name" and "Last Name" fields. By making use of action hooks, it is totally possible to add this functionality. In this post, I'll show you how to get this setup, and how you can add your own rules. Overview To make this work, we're going to be making use of Action Hooks - specifically, the ShoppingCartValidateCheckout hook. If you've never used hooks before, I'd recommend reading our Getting Started guide, which will help you to understand the basics of what we'll be doing here. Step 1: Set up your hook file To begin, open your WHMCS instance's filesystem, and navigate to /path/to/whmcs/includes/hooks and create a new file keyword_filter.php. Now open the file, and paste in the following: <?php add_hook('ShoppingCartValidateCheckout', 1, function($vars) { // Content goes here }); This will tell WHMCS that we are using the ShoppingCartValidateCheckout hook, and will allow us to retrieve the variables provided to us. As this article goes on, we'll be adding to this base layer until we have our finished, fully-functional script. Step 2: Define your keyword filters There are many different ways that we could define what strings are banned in which fields. For maximum legibility and modularity, I've decided to use a map. This will allow us to associate one set of data (the "key"), in this case the field name(s) to apply the filter to, and another (the "value"), which in our case is a list of banned keywords. Here's the code: <?php add_hook('ShoppingCartValidateCheckout', 1, function($vars) { $fieldKeywordMap = [ [ // The 'firstname' and 'lastname' fields cannot contain the strings // "admin", "root" or "superuser". 'fields' => ["firstname", "lastname"], 'keywords' => ["admin", "root", "superuser"] ], [ // The 'email' field cannot contain the strings "@whmcs.com" or // "@google.com". 'fields' => ["email"], 'keywords' => ["@whmcs.com", "@google.com"] ], // Add more mappings as needed ]; }); Each set of 'fields' and 'keywords' is a mapping. You can add as many of these as you need. We'll be returning an error based on whether or not the field contains these keywords (i.e. if they are substrings). For example, if the user enters "admin123" for their firstname and "john.smith@google.com" for their e-mail, both of these filters will apply because the substrings "admin" and "@google.com" are present within the 'firstname' and 'email' fields respectively. You can find a full list of available fields in the documentation for this hook. Step 3: Implement logic to check field submissions for any banned substrings Now that we've defined our 'filters', we need to implement the logic that's going to make them work. Here's the full script, explained in the provided comments: <?php add_hook('ShoppingCartValidateCheckout', 1, function($vars) { $fieldKeywordMap = [ [ // The 'firstname' and 'lastname' fields cannot contain the strings // "admin", "root" or "superuser". 'fields' => ["firstname", "lastname"], 'keywords' => ["admin", "root", "superuser"] ], [ // The 'email' field cannot contain the strings "@whmcs.com" or // "@google.com". 'fields' => ["email"], 'keywords' => ["@whmcs.com", "@google.com"] ], // Add more mappings as needed. ]; // Initialise array to store error messages. $errors = []; // Iterate through all of your mappings. foreach ($fieldKeywordMap as $mapping) { // Get the 'fields' and 'keywords' separately for each mapping. $fields = $mapping['fields']; $keywords = $mapping['keywords']; foreach ($fields as $fieldName) { // Retrieve the value for the field from $vars[] provided by the hook. $fieldValue = $vars[$fieldName] ?? ''; // Check if the field is empty - if it is, skip the checks. if (!$fieldValue) continue; // Check if any of the keywords are a substring of the field value. foreach ($keywords as $keyword) { if (stripos($fieldValue, $keyword) !== false) ) { // If there is a match, add it to the list $errors[] = "'$fieldName' cannot contain '$keyword'. Please remove this and try again."; } } } } // If any errors are present, return them - otherwise, return true. return $errors ?: true; }); Here's a little summary of how it works: Iterate through all of your mappings ('filters') Check all fields for each filter If the field value is blank, skip all checks for that field - we need to do this since this field is only included for new users If the field value is not blank, carry on to checks Check if any keywords are a substring of the field value If they are, add that infraction to an array of errors to be returned If not, do nothing If there are any errors, return them. If all checks are passed and no keywords are present, return true. The only part of this code that you should need to modify is the top section, where you define your filters. If any of the filters are matched, here's what'll be displayed in WHMCS: Step 4: Prettify error messages (optional, but recommended) As it stands, our hook is completely functional. If any banned words are present, an error will be returned. However, our script looks like a customisation, and you'll probably want to make it appear like native functionality. The issues are: We're currently using the $fieldName, which doesn't read like English Language used doesn't fit in with the rest of WHMCS's error messages To second issue is fixed by adjusting the error message, so that's easy! To fix the first problem, we'll use another map to correlate each $fieldName with its "English equivalent" (which I've just called $friendlyFieldName: <?php add_hook('ShoppingCartValidateCheckout', 1, function($vars) { $fieldKeywordMap = [ [ // The 'firstname' and 'lastname' fields cannot contain the strings // "admin", "root" or "superuser". 'fields' => ["firstname", "lastname"], 'keywords' => ["admin", "root", "superuser"] ], [ // The 'email' field cannot contain the strings "@whmcs.com" or // "@google.com". 'fields' => ["email"], 'keywords' => ["@whmcs.com", "@google.com"] ], // Add more mappings as needed. ]; // Map field names that you're using above to their "English equivalent". $friendlyFieldNames = [ 'firstname' => 'First Name', 'lastname' => 'Last Name', 'email' => 'Email Address', // Add more field name translations as needed. ]; // Initialise array to store error messages. $errors = []; // Iterate through all of your mappings. foreach ($fieldKeywordMap as $mapping) { // Get the 'fields' and 'keywords' separately for each mapping. $fields = $mapping['fields']; $keywords = $mapping['keywords']; foreach ($fields as $fieldName) { // Retrieve the value for the field from $vars[] provided by the hook. $fieldValue = $vars[$fieldName] ?? ''; // Check if the field is empty - if it is, skip the checks. if (!$fieldValue) continue; // Check if any of the keywords are a substring of the field value. foreach ($keywords as $keyword) { if (stripos($fieldValue, $keyword) !== false) { // Translate the field name to a nicer name for the error message. $friendlyFieldName = $friendlyFieldName[$fieldName] ?? $fieldName; // Add it to the list $errors[] = "$friendlyFieldName cannot contain '$keyword'"; } } } } // If any errors are present, return them - otherwise, return true. return $errors ?: true; }); Simply add a new mapping for each $fieldName that you use in the $friendlyFieldNames array, and they'll read well and feel like a native part of WHMCS: And there we have it: a hook script that can be easily extended to include as many fields and keywords as you require, and it feels totally native too! Customising/extending this script Feel free to customise this script to you heart's content, whether you want to change how it behaves or extend its functionality. However, please keep in mind that our Technical Support team won't be able to help you troubleshoot any problems that you may encounter should you make any changes. Use at your own risk. Suggestions for other "Tips & Tricks' articles If you'd like to see an example of how we can customise WHMCS in other ways, please do give us your suggestions!

Hello. I accidentally cleared my session on my computer. When i did this i was no longer able to login to my WHMCS admin panel. I tried changing my password but with no luck. I do have a ticket for this issue, but i'm hoping for a quicker answer in the forums, since fixing this is crucial. What i have tried. - From the troublshooting guide i tried to query against the WHMCS database: UPDATE tblconfiguration SET value = 'on' WHERE setting = 'DisableSessionIPCheck'; But this did not work. - I tried uploading the sessiontest.php which gives no error. - I tried to login from a different IP and phone/computer, but i still have the same issue, which is wierd if it's session related. - Using recuva i tried to recover my sessions from Opera. However, that didn't help either so i guess they are corrupted. This issue happened straight after i deleted my cache/sessions. And there was no changes made to any files. I'm also logging in from the correct url. I am using a custom admin panel url. Any suggestions would be appreciated. Thanks.

2018: WGS exposed for bad coding and (probably*) copy-pasting from stackoverflow. 2020: WGS exposed for copy-pasting blog articles. Normally I stay out of competitor bashing, but I couldn't resist... * I don't remember exactly the expose letters.

FWIW, i'm not keen on the use of "Advisors" as one of the ranks - surely, the definition of an advisor is someone who is qualified to give advice??? users making a lot of posts ASKING questions, or replying to their own threads doesn't necessarily mean that they should be giving technical advice (which calling them advisors implies) - for some users, yes that's fine... but I would have thought not for the majority of users with Advisor type ranks... therefore, using the word "Advisor" in the ranks is potentially confusing... I appreciate that you like change for changes sake, and wanted to get away from the generic use of "Members" for everyone, but using advisor just seems silly to me. and don't get me started on "Collectors" - what are they collecting ??? 🙄 btw - why the use of US English in the titles, e.g "Honored Contributor" ?? that looks plain wrong to me. in the meantime, i've taken the liberty of blocking these rank titles in the browser with uBlock, so i'll never have to see them again. 😎 P.S - the search function is seemingly broken, e.g if I search for knowledgebase, it's returning 7 results! if I search my local backup of threads, I can find 96 posts with knowledgebase just in the title - that's not including posts where it might be mentioned in the body.