Guyinpv

NO, the issue is absolutely NOT RESOLVED. Good grief. How many more people have to keep reporting the same issue to you guys and you keep closing their threads as if it’s resolved when it’s NOT?

I already said, I’m NOT repeating all this in some other system somewhere. I reported it here and that’s it. We are trying to give you information, we are putting in the time, the troubleshooting, and you keep ignoring everyone and not fixing the problem.

Use this information and fix your product! Stop marking threads as solved and telling us to go fill in more reports somewhere else all over again. It’s not my job.

You know the product has a bug, so go fix it. Look at all the other threads of people reporting the same thing. It’s been years now.

Thank you!

Maybe it is transients, I don’t know. This isn’t the first time someone has complained that the Site Health report for options is higher than other tools.

For more information, this is why autoload has more options than just “yes”:
https://core.trac.ww.wp.xz.cn/changeset/57920

The query for autoloaded options should be:

WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')

Thanks!

Turns out I didn’t have to wait that long.

I received a message from SiteGround that the “CPU Seconds” were once again filling up for the month.

I checked the access logs and still see quite a bit of activity on the mfm_directory_runner action. On December 24th there were 52,742 calls to admin_ajax with that action. Note that in my settings I have the entire wp-content folder in the exclude list. Not ignore, but exclude. I assume this means the program won’t even try to scan it. This should eliminate all the uploads directory and everything. And all the normal file extensions are disabled as per default. WP core is also disabled.
Unless I don’t know how these exclusions work, shouldn’t that reduce a ton of scanning? Will there still be a lot of directory runner actions even with all this stuff excluded?

Your questions from earlier:

1. Version of WP: 6.7.1.
2. Latest version of plugin: Yes. Updated as soon as 2.2.1 was released.
3. Occurs often or few times: There are spikes on CPU Seconds pretty much every day. Usually around 4-5am and again between 7pm-midnight into the following day. So essentially about twice a day this activity jumps. Here is a screenshot of how CPU seconds looks in SiteGround: https://www.dropbox.com/scl/fi/5svuogl0lah3kwjs1whlk/2024-12-27_13-40-44.png?rlkey=1e3r7njzzb6q64klwy4fwx5il&dl=0
4. How many files: The whole site is 10.9GB according to SiteGround. This is about 92,000 inodes which we can think of as files and folders. But I don’t know how much it is when excluding the WP core and wp-content folder and all the excluded file types.

My first question would be, can I exclude the entire wp-content folder? I’ve had another scanner in the past that didn’t allow excluding wp-content, it could only exclude folders within that folder.

Here is a screenshot of the exclude settings: https://www.dropbox.com/scl/fi/xkdikoch2hlqdf52y8ti6/2024-12-27_13-50-34.png?rlkey=jwf674aol7zzl30h4hmt59jba&dl=0

I guess the question is to figure out if this much traffic to admin-ajax would be normal in my situation. Does the scanner create one hit for every individual file? Or is it one hit to trigger each folder? Or one hit per grouping of X number of files? What should this look like normally?

Thanks for any more ideas, I’ll have to turn off the plugin again so I don’t hit limits.

That could be hard to test since the excessive ajax calls happened quite randomly and only for a few days out of the whole month.

The plugin is now updated to 2.2.1 and it is enabled to scan again.

I’ll keep an eye on it for some weeks but it could be a month or two before I feel comfortable that the issue won’t happen again.

If you avoid closing this thread, I will report back perhaps in February if it hasn’t happened again by then. Or I’ll report sooner if it does happen again of course.

On a side note, when 2.2.1 updated, it went through the wizard asking various questions. One of the questions was to enable/disable the WP core files verification check. I turned this setting OFF because another security plugin already does that. But after the wizard was done, I went into the settings and noticed the WP core check feature was still enabled, so the wizard did not disable the setting. FYI.

Hi,

The issue is not resolved, I’m still hoping you’ll release a fix. It has nothing to do with Filter Bar, the error is from the Tweaks plugin.

I reported a fatal error and gave the reference, that should be enough for you to look into it without telling me to go find some other place to report it all over again, which I won’t do. I’ve reported it here and you’re aware of it and anybody else who has the same issue come up. That should be good enough.

Hi,

This is still a problem. I’ve done the updates over the last month and check on it sometimes. Yes I’ve uninstalled and reinstalled and re-configured, etc.

Now on the latest version, I was able to use the “clear all” function and it did delete every log record, but I could not clear the records one by one, or use the “clear visible” either, they would come right back.