Jump to content


Senior Member
  • Content Count

  • Joined

  • Last visited

Community Reputation

3 Neutral

About linux4me

  • Rank

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. I can confirm that upgrading to v. 7.10.2 fixed this issue for me. Thanks!
  2. I did submit a support ticket, and @WHMCS Alex confirmed that the issue I'm having is linked to case CORE-14548 involving defective queries associated with the client status update, which is slated to be fixed in the next update. Thanks!
  3. I didn't realize I could do that. I've opened a ticket and PM'd you with the ID. Thanks!
  4. Hi @WHMCS Alex It does sound like my issue is related to the one you mention. I get my WHMCS license through my hosting company, so I don't believe I can submit a ticket directly to WHMCS, can I?
  5. Oh, I see what you're saying. You're right, there are no SQL errors--or any others--in the error logs this morning. I looked through the database tables, and I wasn't able to find where this is coming from. I was hoping for a simple flag in the product or clients tables, but I didn't see one.
  6. That's a good thought, but no, that particular client has no add-ons at all listed. I enabled SQL debugging to see if I can catch any failed queries tomorrow when the CSU executes. Today, the activity log still shows "Automated Task: Starting Client Status Update" and no error messages.
  7. I'm using the second one, "Change client status based on active/inactive products." I re-enabled it yesterday, and today the CSU is back to showing "1" for that same client. It seems like there's got to be a flag set in the database somewhere that wasn't updated at some point.
  8. It will be interesting to see what happens. I'll let you know tomorrow.
  9. Hi @WHMCS ChrisD Yes, the product and domain this client has are both active, not transferred, terminated, or canceled. No other clients have had recent changes. Disabling CSU yesterday prevented any client status updates from being listed in today's Cron Activity email, and Automation Status shows "0" for Client Status Updates. I re-enabled "Change client status based on active/inactive products" today, and I'll see what happens with CSU tomorrow.
  10. The only modules I have active are Stripe and eNom, and no third-party modules. I disabled CSU today, and I'll see what happens tomorrow and post back.
  11. I do have Client Status Update set to "Change client status based on active/inactive products," which is what I want it to be doing; however, it seems to think it needs to update that particular client every day though there is no need, as you say. Both his product and his domain are active, and that hasn't changed in some time.
  12. I'm using WHMCS 7.10.1. Every day since I've upgraded to 7.10, I've received the cron daily email showing all tasks completed successfully. The email always includes "Client Status Update 1 Completed." If I go into Utilities -> System -> Automation Status, it, too, shows that cron is running successfully. If I click the detail for the single Client Status Update, it's always the same client. Every day. I've checked his account and it is active, with a valid credit card on file. He has one product and one domain, both show they are active and not due for renewal until 5/13/2020 and 01/03/2021, respectively. I don't see any errors in the Activity Log. It seems like whatever flag is set to tell WHMCS that it needs to update this particular client is stuck, unless there is some reason for repeating the status update daily that I'm unaware of. I tried manually setting the client's status to "active," but it made no difference. This doesn't seem to be doing any harm, but it is annoying. Is there a way to fix it?
  13. I looked in my configuration file, and I don't have that line in there at all, commented out or not. I suspect they added that for debugging, and then commented it out when they were done. Your mention of the language file triggered a memory for me. Take a look at this post regarding my upgrade from 7.4.2 to 7.5. Please do! I'm really curious to know what's causing this, though I think the post above resolves the question about the error messages; I wasn't getting any back then, either. It will be worth testing to see if your error logging works otherwise, just in case.
  14. Well, this is getting more interesting. If you have a white page, you have a PHP error as far as I know. Where is it? In previous versions of WHMCS, the value to enable DisplayErrors was "1," not "on." So I did a little experiment. I set the value of DisplayErrors in the tblconfiguration table to "on" using phpMyAdmin, and confirmed that on Help -> System Health Status that it showed me Display Errors was enabled. So far so good. Next, I edited the file /admin/systemhealthandupdates.php, which is the file that generates the page for System Health Status, and added a PHP error into the file. I refreshed the page, and despite the fact that I had Display Errors enabled, all I got was a white page, no error. I did a little exploring, and found that although I have Display Errors enabled, not log errors, the error message for the error I introduced was in /home/username/logs/mydomain.php.error.log. Have you tried using cPanel's File Manager to see if you have any error log files in your /home/username/logs? That might be where the errors are hiding. I suspect that this behavior may be a conflict between what WHMCS is trying to do and the settings in the php.ini for your account. For example, in mine, I have display_errors set to "off" and log_errors set to "on," so that might account for this. I certainly think it's worth going through and deleting the obsolete files that aren't for your custom template, modules, and configuration, but finding the error message(s) would be my first task. If you have no error log in the folder noted above, you might want to check the settings you have for error handling in the php.ini for the version of PHP your WHMCS installation is using, and make sure log_errors is set to "On." By the way, I found this article, which describes a different method of enabling Display Errors using the configuration file, but my testing suggests that the database method works as well.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use & Guidelines and understand your posts will initially be pre-moderated