Leaderboard

No. HEXONET Status (HTTPS API is usually used by 3rd-party Software Integrations)

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)

That's very helpful to keep track, Thank you !

I'd recommend making a backup of any files you are planning to delete. Better yet, try moving the folder outside of WHMCS document root path. I would keep the files at minimum until you've either confirmed this solution has solved your issue or not. This way you can quickly restore your WHMCS back to its previous state in case of any unforeseen errors.

That is true. I talked to both vendors, and they told me to contact WHMCS.com

Another day another ignored WHMCS bug as this thread surpasses 60k views. Today I had a client create an order, pay via PayPal. No client account created, no order created in WHMCS. No payment received to PayPal. Client sees the transaction in PayPal which disappears within a couple of hours. Very bad look as a user of WHMCS who has seen constant price rises for software that supposedly is all about automation and ease of use. This is 100% a WHMCS bug as I've seen the exact same with Stripe. Other times the client account is created, the order created but the payment is "uncaptured" No point submitting a ticket as WHMCS refuse to accept this is an issue with their software. I now use almost stock WHMCS. Just Fraud Record in terms of modules and I have a very simple child theme of twenty one.

Custom fields are a pain to deal with in WHMCS. Other than placing a {break} if the field is found, there's not really more optimization that can be done - unless you can access it by $customfields.17.value, which I assume you can't.

@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. ❤️

Loads fine in Firefox, but Vivaldi (and a few others) sees what he does. Related to a javascript that's loading. It's a webpros script.

If it's a paid addon, it's unlikely that would be ok with the seller, though I'm sure others (and myself) would like to try and spot the issue.

Hi @elonmusk, The LocalAPI user is invoked locally. Ie. By a file on your website that isn't a part of the stock WHMCS software. This will likely be an after-market customisation, perhaps something like a custom order form. I suggest comparing your WHMCS files against the stock ones for any additionals you may have, as they could be the cause.

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

Go to the client which seems to be created by API and there is last tab Logs

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

@elonmusk Check log with which API user it's getting created So you can edit the role assign to that user and remove API access Hope this will help you

@Dkuzik in $_CONFIG you will get "MailConfig" element, You need to decrypt() the value of MailConfig. The decrypted value will return JSON containing SMTP setting. You can use the API to decrypt Data https://developers.whmcs.com/api-reference/decryptpassword/

Yes we created that , it works perfectly.

It would possibly benefit you to create a custom field associated with domain to store timestamp of registration. Then each 10 minutes, check custom field value of the most recent/highest domain if the value satisfies the requirement. If false, stop querying. If true, repeat query, highest domain id not previously checked within this cron. Repeat until a false is returned.

You can create one custom table where you maintain the domain register with hook PreRegistrarRegisterDomain with date and time https://developers.whmcs.com/hooks-reference/domain/#preregistrarregisterdomain Then write cron for every 10 min, get record from your database table do the needful operation

Hi @3cellhosting, The directory can be safely deleted /vendor/whmcs/whmcs-foundation/lib/Installer/Composer/Hooks/ along with its contents. You can then run the update process again and this time the error will not occur.

Hello, The tbllog_register table holds data on the actions taken by the daily cron tasks which are available in the admin area at Utilities > Automation Status. It is where the results of a cron task are stored. The daily cron email report aggregates its content from these rows. These are the actions taken by the daily cron tasks which are available in the admin area at Utilities > Automation Status. At present it is not possible to prune this log from within WHMCS. If you'd like to see this included I'd encourage you to add your vote or comments to https://requests.whmcs.com/idea/cleanup-tool-to-prune-tbllog_register-table Ideas with the most votes and activities are reviewed by our team. As of WHMCS 8.1 and above we have optimized the indexing for cron log data. https://docs.whmcs.com/Changelog:WHMCS_V8.1 CORE-14970 - Optimize indexing for cron log data In the meantime, if this is something that you would like to work with, you can do so with a SQL query. For example, the SQL query below will remove any entries in that table that predate 2023. You can modify this to suit your requirements. DELETE FROM `tbllog_register` WHERE created_at < "2023-01-01"; As always, please ensure you back up your database before performing any such direct actions on the WHMCS database.

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.

Nice to be a part of WHMCS Community Thanks,

Thank u very much. I can extract data. Now let's see if I can make it work for me. For some reason decryptpassword() didn't work for me. decrypt () worked

I have disabled user registrations since I am using WHMCS. The only way to create a user is when someone orders a service, and I didn't see any orders or order emails in the logs.