Hi @rdwebstuff24,
If automatic rules updates have been working fine up until now, file and database permissions are likely to be OK unless something has changed at the host’s end recently. Am I right in assuming from your question that manually hitting the update button works? If it does, then there may not even be a problem with the files involved. It’s still worth a try to clear them out, though.
Manually removing the wp-content/wflogs folder’s contents (or the whole wflogs folder) via FTP or hosting file manager should stand a good chance of solving the issue as a file may have become corrupt. Wordfence should try to recreate the folder and files automatically within 30 minutes (usually much sooner).
You can bypass using the wflogs folder entirely by setting logs to use the MySQLi storage engine instead if you wish: https://www.wordfence.com/help/firewall/mysqli-storage-engine/
If none of that helps, see if any of your WP Cron jobs are overdue. We provide this on the Wordfence > Tools > Diagnostics page under “Cron Jobs”. The automatic rules updates along with scans and other WordPress plugins may be affected if those aren’t firing.
Many thanks,
Peter.
Hi Peter, thanks for getting back to me. This hasn’t just happened I don’t think. This website never did these automatically I don’t think.
I have deleted that wflogs folder and refresh the site. That message came straight back up. I will wait the 30 minutes to see what happens.
I refreshed the rules manually because the message was still there. When I look at the cron jobs there are items there from yesterday that should have been done. 11 items from 16th.
What wouldl you suggest now.
I looked at bypassing the wflogs folder but that looks abit daunting to do??
Hi @rdwebstuff24,
I suspect that if the crons are becoming overdue then that is more likely the issue than the difference between using the /wflogs files or MySQLi, so don’t worry about changing that for now.
You may need to ask your host if there are any errors in your PHP/server logs around the time those are scheduled to run, if you can’t check them yourself. Sometimes a conflict or broken plugin hook can silently kill the entire WP Cron queue. This can also be linked to max_execution_time. It’s worth ensuring your max_execution_time is 60 or less (but not 0 which is “unlimited”) in php.ini and WP_MEMORY_LIMIT is 256M or higher in wp-config.php.
Thanks again,
Peter.
