Leaderboard

I'm opening this thread to link my feature request (please share/vote it) and discuss about the possible solutions we have to overcome these issues before WHMCS intervention. For simplicity reasons I'm going to post the request here since Feature Request doesn't support formatting. I've never been a Registrar myself but it seems that some of my customers desperately need two things in WHMCS: Specify registrant details when using DomainRegister and DomainTransfer API functions WHMCS must preserve registrant details upon order creation to prevent profile changes for existing orders Both things are equally important and I'm going to show you why. 1. PREVENTING LAWSUITS This is a serious problem for mid/large size enterprises using WHMCS. Let me explain what I mean with an example. A customer transfers 100 domains and creates the following contact to use as registrant information - Don't worry, I'm using fake details: Fiorenza Panicucci TIM S.P.A. tim@example.com Via Callicratide 24 Ussel AO 11024 IT - Italy +39.03102578690 As you know, it may take some hours/days before all transfers complete. In the meantime the customer updates this contact details like follows: Fiorenza Panicucci TIM S.P.A. fiorenza@example.com <--- CHANGED Via Callicratide 24 Ussel AO 11024 IT - Italy +39.03102578690 Then he proceeds to transfer 100 more domains placing a new order. At this point we have 2 orders each one with 100 domain transfer both linked to the same contact. We all would would expect WHMCS to process the 1st order using tim@example.com email address and fiorenza@example.com for the 2nd but WHMCS has other plans. Both orders will be processed using fiorenza@example.com email for the simple reason that WHMCS doesn't store registrant data snapshort. The reason why customer placed 2 separate orders was exactly because he wanted use different emails but WHMCS just picks the "live" data. The consequences of this behaviour are distruptive since customers can update all details anytime (company name, telephone number, address...) with orders that are still in progress causing hundreds of domains to be potentially registered with wrong data on a daily basis. If you have lot of domains this is the worst of your nightmares since: You need to fix all information manually at Registrar level. It can cost you a lot of money to spend for domain trades Domain owners are angry and disappointed. Lawsuits are Just Around the Corner... and they're 100% right! Please don't think that preventing customers from updating contact details is the solution. It will simply force customers to register an enormous number of contacts just because they need to use a different telephone numbers for specific domains or when they need to register X and Y for their company and W for themself. Not to mention that WHMCS forces email addresses to be unique. Believe me, I have already tried this solution over the years with tens of mid/large sized WHMCS systems and this is a complete nonsense. Keep in mind that this was just an example. The problem described above can occurr in different ways also with registrations and ironically it gets worse when orders have a small number of domains. On a large scale it makes daily checks close to impossible. Over the years I had customers paying fines or literally buring money for unnecessary domain trades that were super expensive! 2. INTEGRATIONS This part is less scary but still relevant. I work with customers that have heavily customized systems to the point that no one uses WHMCS cart at all. We're talking about 100% custom-made ordering processes that transmit data to WHMCS via API. The only thing we can't get is to register/transfer domains via API providing registrant information "on the fly". I hope I don't need to explain why this is important. We should have something like follows: <? $postData = array( 'domainid' => '1', 'registrant_firstname' => 'Mark', 'registrant_lastname' => 'White', 'registrant_companyname' => 'Dragon Ltd.', 'registrant_email' => 'mark@example.com', // ... and so on ); $results = localAPI('DomainRegister', $postData); ---------------------------------------------------------------------------------------- At the moment I can't find any viable way to cope with both needs. All solutions I came up with are impractical. They would require me "deactivate" core features of WHMCS replacing them with my own ones writing an enormous amount of code but I have a life 🙄

I hate to suggest this, but it would probably be quicker to switch back to using Modern for registrations.

Removing the 1 year option is definitely not ideal, as some clients will want to drop it back down.

you could edit the error template(s) - /templates/six (or custom)/error/internal-error.tpl as that will be the template generating the above output.... you can alter the content of that page, including removing the stacktrace. <div class="error-container"> <h1>Oops!</h1> <h2>Something went wrong and we couldn't process your request.</h2> <p>Please go back to the previous page and try again.</p> <p>If the problem persists, please <a href="mailto:{{email}}">contact us</a>.</p> <p class="back-to-home"><a href="{{systemurl}}">&laquo; Back to Homepage</a></p> {{environmentIssues}} <p class="debug">{{adminHelp}}<br/>{{stacktrace}}</p> </div>

Ah, okay. Use the EncryptPassword function instead: https://developers.whmcs.com/api-reference/encryptpassword/

You can use the DecryptPassword API function to decrypt it: https://developers.whmcs.com/api-reference/decryptpassword/ Something like this <?php include_once 'init.php'; $SMTPPassword = Capsule::table('tblconfiguration')->value('SMTPPassword'); $command = 'DecryptPassword'; $postData = array( 'password2' => $SMTPPassword, ); $results = localAPI($command, $postData); print_r($results); The code above is not tested, but something like that would work for you.

they would have a value of "on" if they have been ticked. the problem with custom fields in this context is that there are (or can be) multiple fields (and their values) that may or may not apply for any given domain/service... the default WHMCS reports all tend to expect value per field... so what's required in your case is more than a little tweak. it does - what you will need is effectively two custom reports (ine for domains, another for services), using new filenames to ensure that they're not overwritten during a WHMCS update. I see that you've started a SO&R thread, but it's worth noting that developers in such threads will not publicly post a price for projects like this, they will all ask you to go to their sites and complete their contact forms... and then give you a quote privately.