steven99

That may be a Plesk issue more so than a WHMCS issue. In Plesk -> Tools and settings -> IP Addresses -> the private IP, do you have the public IP field set? Is that set in production setup?

Do not think that is built in but would be a good feature for that password expiration addon you mentioned. Would require at least the ClientChangePassword hook. I do not believe that provides the old password and so you would need another hook, like the ClientAreaPageChangePassword, to capture the old password and store it, still hashed, in the session. Then on ClientChangePassword, check that session variable against the new password hash. If it matches, well then you have to force them to password change page via a ClientAreaPage hook and complain that they match.

Just a quick note, nearly every Eloquent (Laravel database manager) information will apply here.

Hook: ServiceEdit . Other documented hooks: https://developers.whmcs.com/hooks/hook-index/

FOSSBilling install is uploading the PHP files to a web server and setting up a database and going to the script's install URL. How is that advanced? How did you install WHMCS? Granted if you use the development builds, it does get more involved with composer. However, dev version for something used for production should not be used. And even they say don't use any version at this point for production.

A quick, very rough example, of doing this in code would be: $client = Client::find(124433); $client->createRemoteCardPayMethod('authcim', '1234', "1299", "authnet_123abciyez" ); https://classdocs.whmcs.com/8.6/WHMCS/User/Client.html You could use the $client->payMethods() function to get the current methods, find the stripe one and get its data via Stripe API. Then check authorize.net API for a matching client and last 4 and expiry date and add using the above. Did not have time to check what paymethods returns, but likely an array of tblpaymentmethods objects or array of them. print_r /vardump to log to find out. Once you matched it up, use the above function and you're done.

I presume you are using the addbillingitem api call and that you are using hours. If so, the variables should be: $postData = array( 'clientid' => 1, 'description' => "Coffee", 'amount' => 500, 'invoiceaction' => "nextinvoice", 'quantity'=>1, 'unit'=>'hours' ); If you're not using hours, then just get rid of "unit" completely so the variables look like: $postData = array( 'clientid' => 1, 'description' => "pizza", 'amount' => 100, 'invoiceaction' => "nextinvoice", 'quantity'=>5, );

Out of the box, nope. You could edit the database and update each client's gateway token to the new token, however, IIRC the payment method entries are encrypted and/or in a binary column and can't easily be changed. An addon that does that "the proper way" is probably best. On a related note, was not aware authorize.net could import Stripe data and be able to charge the cards. IIRC, none of their API functions returns the full card info. So sure they have the client info. So I suppose there is a behind the scenes data swap between the two...?

For docs on the Domain model, check: https://classdocs.whmcs.com/8.6/WHMCS/Domain/Domain.html . Change version to version in use for that specific one. Using capsule directly will not produce the model and just the direct database data for the domains table. You will get essentially the same info but in some cases the Model will have different variable names then the database column names. So using one over the other depends on a few factors.

With the EPP being slow, for some items using a cache might be better. Save domain info for example to a session variable with a date variable indicating when it was cached. Then before doing the EPP request, check if cache is available and is recent enough to be used. If cache is available and recent, then return the data variable held in the cache. if its to old, then get the info again and save that request to cache for the next time.

The license module is mainly for developers to license their own modules or other software. The license checking and such would be within your own project's code - be it a wordpress plugin or a WHMCS server module.

If using friendly URLs, that may not work as the "action" _GET variable is missing in many URLs now.

A PreModuleTerminate hook could be used to catch the terminate and then an API call to suspend the service would be done and then returning the abort value in the PreModuleTerminate hook .

And what exactly is the issue? I am guessing it is doing the infinite login loop without saying if the login was good or not. If so, that is indeed sessions or cookie issues . If the server's sessions are working, then check that your session cookies are actually being saved.

Shockingly (lol) the docs are slightly wrong. The $domain is an array, that is holding a "domain" item that is then the Domain object. So it should be: <?php add_hook('ClientAreaDomainDetailsOutput', 1, function($domain) { //passed $domain might be object or might be array, lets test if (is_array($domain)) $domain = $domain['domain']; // Replace domain array with domain object $domainName = $domain->domain; $clientModel = $domain->client; $domainStatus = $domain->status; $clientName = $clientModel->firstName . ' ' . $clientModel->lastName; return 'You can place any HTML here that will be output in the $hookOutput smarty variable array'; }); Would have been quite surprised if it was indeed a domain object but maybe that is in a later version than my dev is at right now. Also, objects are great and embrace them you will. 😉 Whenever you are questioning what WHMCS is giving you, just do: logActivity("What is this junk: ".print_r($the_thing,true)); or logModuleCall("hook-hookname", 'I-did-it', "I asked for this and got", "only this short message", $processedData, $replaceVars);