• Resolved staze

    (@staze)


    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!

Viewing 14 replies - 1 through 14 (of 14 total)
  • Stef

    (@serafinnyc)

    @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;"
    Thread Starter staze

    (@staze)

    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
    Stef

    (@serafinnyc)

    @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.

    Thread Starter staze

    (@staze)

    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?

    Stef

    (@serafinnyc)

    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!

    Thread Starter staze

    (@staze)

    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…

    Stef

    (@serafinnyc)

    @staze

    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.

    Thread Starter staze

    (@staze)

    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…

    Thread Starter staze

    (@staze)

    Related, is something like this still “safe”?

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

    (@serafinnyc)

    @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!

    Stef

    (@serafinnyc)

    @staze PLEASE do not use that command. That’s very dangerous. Just turning things to no is safer.

    Thread Starter staze

    (@staze)

    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?

    Stef

    (@serafinnyc)

    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.

    Thread Starter staze

    (@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 5 months, 2 weeks ago by staze. Reason: marking resolved
Viewing 14 replies - 1 through 14 (of 14 total)

You must be logged in to reply to this topic.