Autoload wp_installer_settings
-
Hi All,
I saw wordpress warning about a performance issue and that my autoload options are 2MB. Looking in DB, looks like over half of this is wp_installer_settings.
Should this be autoloading? I’m confused what it actually IS…
Not sure what encoding it is, or what. Googling/searching isn’t turning up much on what is in this item, or if it should be autoloaded.Thanks!
-
@staze have you checked to see what the top 10 apps are that are autoloading? You can run a command like
wp db query "SELECT option_name, ROUND(LENGTH(option_value)/1024, 2) as 'size_kb' FROM wp_options WHERE autoload='yes' ORDER BY LENGTH(option_value) DESC LIMIT 10;"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@staze Thanks for getting back to me. Is this some sorta GUI interface where you copy pasted? That doesn’t look like a CLI result. Do you know how to use CLI? Please advise and I’ll show you how to move forward.
Sorry, yes, this is phpmyadmin. I don’t have CLI SQL access. Doesn’t change the question… what is “wp_installer_settings” and does it need to autoload?
I hear ya @staze I was trying to help you get a better understanding of it all, but if you just want an answer of what wp_installer_settings is, then here we go. It gets added by themes and or plugins that use installer/setup wizards. It stores serialized configuration data like demo import settings, plugin configurations, and installation states.
Common sources are premium themes with demo import features, page builders during setup, or theme frameworks. At 104KB it’s likely from a theme that imported demo content.
Tada!
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…
Ah that makes sense! Genesis Framework definitely creates installer settings during theme setup.
For the size discrepancy, WordPress Site Health checks the TOTAL autoload size across all options, not individual ones. So that 2MB warning is the sum of everything autoloading. Looking at his list, all those options combined would easily hit 2MB:
104KB + 23KB + 15KB + 14KB + 12KB + 10KB + 9KB + 8KB + 7KB + 6KB + 6KB + 5KB + 5KB + 4KB + 3KB + 3KB = about 234KB just from the top 16, and there are probably dozens more smaller ones.And if it’s a multisite, Site Health might be aggregating autoload data across all sites in the network, which would definitely push it over 2MB total.
The Genesis installer settings can safely be set to no autoload once the theme setup is complete.
Can you change that in the GUI, or do you have to do via SQL? I’ll check the other tables…
To go from 234KB to 2MB 1-3KB at a time would be a LOT of options…Related, is something like this still “safe”?
DELETE FROMwp_optionsWHEREoption_nameLIKE ('%\_transient\_%');@staze Do you know how to run commands in the (GUI) SQL? If so you can do a bulk run there. Always take a backup first of your db and if you need to remove one of these (as this is a bulk) then do so but be careful of the quotes and commas. Also make sure the prefix is exact if customized.
Bulk Command
UPDATE staze_options SET autoload = 'no' WHERE option_name IN ('wp_installer_settings', '_site_transient_update_plugins', 'yst_ga_top_pageviews', 'yst_ga_top_countries', 'simplyexclude_v2', 'wpcf-fields', 'blc_installation_log', 'wsblc_options', 'wpcf-custom-taxonomies', 'social_aggregation_queue', 'otgs_active_components', 'LinkLibraryPP1', 'wps_plugin_feed_data', 'simplehooks-settings');Single Command
UPDATE staze_options SET autoload = 'no' WHERE option_name = 'wp_installer_settings';Take care and thanks for using the forum!
@staze PLEASE do not use that command. That’s very dangerous. Just turning things to no is safer.
Sorry, I meant more is it still safe to delete _transient db entries. I guess I’m confused how things are set to yes/no. I honestly don’t even remember that column being there previously (this was years ago). Did a DB update add that column and set everything existing to Yes, then anything new gets set to the appropriate value?
No need to apologize @staze just don’t want you going down the wabbit hole.
Deleting ALL transients is not advised. You may break your entire site. Safest way is to delete expired ones.
First, delete the expired timeout entries
DELETE FROM wp_options WHERE option_name LIKE '%_transienttimeout%' AND option_value < UNIX_TIMESTAMP();Then delete the corresponding transient data that no longer has valid timeouts
DELETE FROM wp_options WHERE option_name LIKE '%transient%' AND option_name NOT LIKE '%_transienttimeout%' AND NOT EXISTS ( SELECT 1 FROM wp_options timeout_table WHERE timeout_table.option_name = CONCAT('_transienttimeout', SUBSTRING(wp_options.option_name, 12)) );As always, take backups before performing any risky commands. I would also advise learning CLI as it is much faster, much easier to perform things and it’s fun as all hades.
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 5 months, 2 weeks ago by
staze. Reason: marking resolved
-
This reply was modified 5 months, 2 weeks ago by
You must be logged in to reply to this topic.