shoelaced

I'm not really an SQL expert but I think this should do it: $sql = "DELETE FROM tbllog_register WHERE namespace = 'RunJobsQueue.executed' AND created_at < :date";

Yah just update the SQL command in the script.

@Dallin121 I created a gist of the solution I'm using based on @linux4me's solution in the above mention, but yeah just bear in mind that it'll delete the historical cron records. I don't really care about the cron records and I haven't noticed any other issues but it's possible I might regret it later, ha. Anyway, be sure to create a backup first.

I did some minor refactoring of this and it still seems to work, thanks @linux4me Here's my gist if anyone's interested. Weird that WHMCS doesn't include a native solution for this. There must be databases that are bloated out of their minds. I only had records going back to 2018 and it had like half a million rows in there and was getting to the point where the database download during the WHMCS upgrade process was not working at all. This probably explains it, ha.

Just wanna say that I'm enjoying that we're already on 8.0.2 and it would be great if you could please continue sending out the updates so we can finally stop with all of these obnoxious hotfixes that no one ever sees until it's too late. On the topic though, it would be helpful if you included a message during updates that says whether there are any changes in the default themes, so that those of us who used them to build custom themes will know whether we need to update them. Thanks, best version yet.

Checking out 7.10, looks cool so far. I was wondering about the new TLD sync feature. The importer only gives the option of markups, but I prefer to sell all my TLDs at the same price, which means different markups for different TLDs. If I sync the TLDs I currently sell, can I just leave the markup field blank and keep the prices I currently have set? Or am I misunderstanding the purpose of this tool? Is it necessary to sync TLDs that were set up via WHMCS in the first place, or is this tool only intended for TLDs that were set up directly with the registrar?

I tried that, doesn't seem to work - although setting it to Basic URLs makes it do what it was doing before, where it would just stay on the login screen and print a message about the page being restricted. Maybe because I have the "always redirect to login" option turned on... I'll have to try turning that off when I have a sec. I only use it for my private clients for whom I manually make accounts, so the whole site is only accessible after logging in.

Ha. Okay, well... any ideas on how I can debug this?

Thanks for the reply. Just tested the Six template and it doesn't work either. When I hover over the button Chrome does say that it leads to https://mydomain.com/password/reset/begin, but the url in the url bar is https://mydomain.com/password/reset/login.php, and it gives me the too many redirects error. If I put the /password/reset/begin url into Redirect Checker, it produces the following (obviously I used my real domain): Result https://mydomain.com/password/reset/begin 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found login.php 302 Found So for some reason it appears to be getting caught in an infinite loop back to login.php. In my WHMCS settings I have the Friendly URLs on "Full Friendly Rewrite," which is the system-detected setting and I've clicked the little refresh icon there, which opts for Full Friendly Rewrite as well. But I've tried all the other URL settings and none of them work either. One thing I'm noticing is that when browsing around in the client area (everything else works fine), the URLs are all things like ?action=invoices, whereas I thought the Full Friendly Rewrite would make it something like /invoices. Is that normal?

I have, as far as I know. I keep my custom theme in a Git repository so whenever there's an update I just delete my theme, FTP into the Six directory, copy everything down, and then just go through and discard all my changes that I want to keep (which are very minimal and mostly CSS) from the commit. Assuming the Six theme in my WHMCS installation gets updated along with everything else, my custom theme should practically just be a re-styled version of the latest Six. I just checked and my pwreset.tpl template is in fact empty... Is https://mydomain.com/password/reset/login.php the correct url for the password reset form? I'm not sure why it would be going through too many redirects after syncing the rewrite rules, given that previously my .htacces was completely empty. Now it only contains the auto-generated WHMCS rules.

Update - I found that my "URI rewrite management" rules were out-of-sync and the auto-managed rewrite was turned off, and I am on an Apache server so I tried turning it on and syncing it. Now the password reset button tries to send me to "https://mydomain.com/password/reset/login.php" but it gives me a "too many redirects" error in the browser (Chrome). mydomain.com/pwreset.php still works though, so I suppose I'll just keep updating my theme to that...

Hi all, The password reset button hasn't worked for a long time for me - I keep hoping a new update or a hotfix will fix it but I just updated to 7.9.2 and still nope. What happens is that when the user clicks the password reset button, it stays on the login screen and says "restricted." In order to fix it I have to go into my (custom) theme and change the placeholder in the button's `href` attribute to a hard-coded link to https://mydomain.com/pwreset.php. After that it works fine. It's been an issue for several releases and I figured if it was an actual bug there'd already be a fix for it, but I'm not finding other reports about it, so I'm guessing it's on my end somewhere but I have no idea what could be the issue. Has anyone else experienced this?

@WHMCS John , Thanks for the reply. Yes, I've just tested it and it also happens when I switch to Six.

Hm, okay update - If I choose PayPal Basic in the invoice, the buttons show up, but if I choose the new PayPal module, there are no buttons at all. Obviously this means I'm going to have to use the PayPal Basic module instead of the new one, so I assume this is a bug in the new module?

Also I should note that I am using a custom template, but I've already updated it and ensured that the code there is correct.

So I just updated from 7.8x to 7.9.1. Then I activated the new PayPal module and de-activated the old PayPal Express and PayPal Basic modules, then I read that we apparently still need the PayPal Basic module for subscriptions, so I re-activated it and added my API creds back in. Now it seems that there are no buttons in the invoices where the PayPal method is selected. If I set it to Credit Card the "pay" button shows up, but when I switch it to PayPal there are no buttons at all. So... is this an issue anyone else has noticed and is there a way to fix it?

@bigsean My issue (I think?) seems to be okay now after I installed the Payment Gateway hotfix, but I still have no idea about the others, and I haven't installed them. If @brian! says to install them in that order then I'll probably try that too. Frankly, as @brian! also mentioned, I can't understand why they don't update the core when new hotfixes are released or bump the minor version so we can just install the damn things from the admin. This makes it a huge pain and we never know there's an issue or a hotfix until a CUSTOMER points it out, which obviously is very non-ideal. Hope they do something about it someday. As full-featured as WHMCS is it'd be nice if they started making it less clunky.

@WHMCS ChrisD - sorry, where do I open a support ticket? WHMCS comes included with my reseller hosting plan through my host, so I'm only aware of this site.

Thanks for the responses. So @WHMCS ChrisD, is the most recent one based on when it was posted, or when it says it was updated? For example for 7.8.3 it says that the Payment Gateway Issues one was most recently updated, but the Call to undefined function one was most recently posted in the first place.

I have a question about the Hotfixes - if there are multiple for the same version of WHMCS and they contain the same file, are we supposed to manually combine the two versions of said file? For example, if I apply the CORE-13801 for v. 7.8.3, and then also want to apply the Payment Gateway Issues hotfix for v. 7.8.3, they both contain some of the same files, so if I download and replace as the instructions say, won't the second hotfix un-do the changes from the first? How do we apply multiple hotfixes?

Hi all, I'm encountering a weird issue where it looks like one of my clients tried to go in and pay their invoice with a credit card, but for some reason there's no record of it in WHMCS. Only in Stripe. Basically in WHMCS it basically looks like the client hasn't added a card or tried to pay the invoice, yet there's a transaction in Stripe for that invoice. In WHMCS, the invoice says "Unpaid," there are no transactions listed, and there is no credit card on file. The customer was sent an invoice payment reminder email, but nothing else. But in Stripe, I'm seeing a card on file and a transaction that failed due to insufficient funds. It shows an error in the Log (attached), but I don't know if that error is because the card was declined or because it couldn't connect back to WHMCS to update the invoice. It's working with my other clients, so I'm not sure why it wouldn't be working with this one. The only thing I can think of is that there may be an issue in WHMCS 7.8.3, because this client is the only one who's tried to add a new card since I updated - all the other clients already had a card on file. The weirdest part is that my client must've added their card through WHMCS but there is no card on file for them. Maybe they added it and then deleted it? Or maybe they paid the invoice and the info got sent to Stripe, and maybe Stripe did send back the info about the failed transaction, but for some reason nothing is saving to the database? Does anyone know what the issue could be and if there's a way I can manually trigger Stripe to try again so that the invoice and the client's card on file gets updated in WHMCS? UPDATE: I'm now noticing this Hotfix but not sure if this problem is related:

Yes, my question was whether the password gets deleted when Google sign in is activated, which I would think would be the ideal default behavior for security's sake. The password would remain intact if the customer is not using a social login. The way it is now if a customer has activated social sign in, then their password just sits there. Since they never use it to log in they'll never remember it anyway, nor think to change it if it gets compromised. It would just sit there as a security hole in their account forever.

Are customers able to sign up with Google sign in? What happens then, does the system just generate a password for the account? Seems like storing a working but unnecessary password negates all the security benefits of Google sign in, but okay.

Title says the gist. The main reason I would want to offer Google sign in would be for security's sake, in the sense that if a user activates Google sign in, then their login ability would be handled by Google and I would no longer be storing their password. Obviously I don't expect a data breach, but it seems like if a user no longer uses their password, then I might as well no longer store a password for them on the off-chance that it does ever happen. In any case, I was wondering what WHMCS does with stored passwords when a user activates Google sign in, if anything.

Ah okay, so to clarify, the client does not receive both emails, right? Only one or the other depending on whether they have a card on file? Does the client also receive the regular "Invoice Payment Reminder" email when the method is set as Credit Card? And are the credit card emails sent based on the number of days set by "Invoice Unpaid Reminder" in the Automation settings, or are they sent in lieu of the invoice?