staze

So found a plugin from Joost that shows all options. Turns out the culprit was bbb_badbots that must live in another table. Nuked that (uninstalled plugin and then nuked it) and now I’m much better.

“When you started on 2025-09-03 you had 559 autoloaded options, for 2,392.7KB of memory. Now you have 559 options, for 241.3KB of memory.”

=)

• This reply was modified 9 months ago by staze. Reason: marking resolved

Related, is something like this still “safe”?

DELETE FROM wp_options WHERE option_name LIKE ('%\_transient\_%');

Gotcha. I use Genesis Framework, so maybe that’s it.

Good catch on it only being 100kb. I for some reason read as 1mb. So the health check must be seeing either all wp_options autoload or not, or it’s seeing them from all the sites in my multisite setup…

Yes. And that’s what brought up the top hit of of “wp_installer_settings”.
SELECT option_name, length(option_value), autoload FROM staze_options WHERE autoload=’yes’ ORDER BY length(option_value) DESC LIMIT 20;

Edit Edit   Copy Copy   Delete Delete   wp_installer_settings   104100  yes
Edit Edit   Copy Copy   Delete Delete   _site_transient_update_plugins  23121   yes
Edit Edit   Copy Copy   Delete Delete   yst_ga_top_pageviews    15643   yes
Edit Edit   Copy Copy   Delete Delete   rewrite_rules   14644   yes
Edit Edit   Copy Copy   Delete Delete   wp_user_roles   12812   yes
Edit Edit   Copy Copy   Delete Delete   simplyexclude_v2    10795   yes
Edit Edit   Copy Copy   Delete Delete   wpcf-fields 9673    yes
Edit Edit   Copy Copy   Delete Delete   blc_installation_log    9143    yes
Edit Edit   Copy Copy   Delete Delete   wsblc_options   8851    yes
Edit Edit   Copy Copy   Delete Delete   wpcf-custom-taxonomies  7660    yes
Edit Edit   Copy Copy   Delete Delete   social_aggregation_queue    7208    yes
Edit Edit   Copy Copy   Delete Delete   otgs_active_components  6437    yes
Edit Edit   Copy Copy   Delete Delete   wpseo_titles    6339    yes
Edit Edit   Copy Copy   Delete Delete   wp_5_user_roles 5753    yes
Edit Edit   Copy Copy   Delete Delete   LinkLibraryPP1  5498    yes
Edit Edit   Copy Copy   Delete Delete   wpseo   5178    yes
Edit Edit   Copy Copy   Delete Delete   yst_ga_top_countries    4897    yes
Edit Edit   Copy Copy   Delete Delete   wp_7_user_roles 3587    yes
Edit Edit   Copy Copy   Delete Delete   wps_plugin_feed_data    3464    yes
Edit Edit   Copy Copy   Delete Delete   simplehooks-settings    3317    yes

confirmed fixed. Thanks!

Hi @wfmattr Any update on this?

Understood, thanks @wfmattr.

And yes, certainly not wanting to give access, but I work in tech, and sometimes you need to get get eyes on the actual problem when you can’t reproduce internally. =)

So I assume the reality here is I converted a standalone install to multisite, so my “blog.1” just stayed using uploads, and the others converted over to using blog.X as I imported them into the multisite. tbh, I’m now curious how modern multisite handles this as if they all use uploads, that could lead to naming collisions (two sites uploading the same file in the same month).

I’m honestly not sure where WF is getting blog.1 as it doesn’t seem to be defined anywhere. I’m also not sure how it’s looping back out to think stuff in wp-admin is in wp-contents/uploads unless it’s part of wordpress handling non-existent URLs and WF isn’t checking for a redirect.

Glad to hear a fix is on the way. No rush on this. I can ignore the warnings for now. I’d rather not exclude directories from scanning since that would potentially hide actual threats.

Thanks again!

@wfmattr,

1. UPLOAD isn’t defined in WP-Config.php.
2. blogs.dir does exist in wp-content, but /1/ doesn’t exist within that. Looking in All Sites, Edit (for “Upload Path” and “Upload Url Path”), my first site is site 2, and my primary site is set to use wp-content/uploads.
3. There’s no rewrite for blogs in my .htaccess.

Because it’s multisite, WF runs from Network dashboard, which might be issue?

Not sure what else to look at. Happy to look in DB if needed.