Option fs_accounts, which is very large, has the autoload flag set to true

[daigo75]

🐞 bug report

Behavior:
A client reported that option fs_accounts has the autoload property set to yes. Apparently, that option is also large in size, so this automatic loading affects the performance significantly.

The autoload flag seems to be set by method FS_Option_Manager::store(), which uses property FS_Option_Manager::$autoload. Based on a quick inspection, that property is always set to null, which means that it defaults to true when function update_option() is called.

The fix could be as simple as setting the autoload property to false. That should prevent WordPress from unnecessarily loading the option.

Versions: (*)

• Freemius SDK Version: 2.4.2
• WordPress Version: 5.7.x
• PHP Version: 7.2-7.4

Plugin / Theme: (*)

• Name: Aelia Currency Switcher for WooCoommerce
• Slug: woocommerce-aelia-currencyswitcher
• Freemius ID: 6708

Note: this affects any plugin, or theme, using the WordPress SDK.

[lkraav]

Probably duplicate of #400

[banago]

And I have two of those. Not acceptable. This needs to be a transient, or at least not auto-loaded.

[vovafeldman]

Yep, as @lkraav mentioned this is a dup of #400

We are aware of the issue and will eventually address it (unfortunately, due to other priorities there's no ETA).

@banago I'm not sure how you can have two options with the same option_name in the same DB, so that's awkward. The option cannot be fully moved to a transient as it holds non-temporary data. There are more insights about the option in my comment here.

[skullo27]

Hello, I am not a developer but use plugins that use this Freemius SDK. What I do know is that setting wp_options entries to autoload when unnecessary is not just bad coding, it is just plain lazy.

I imagine it is not very high up the priority list to fix as most users either do not understand what autoloads on the wp_options table are or do, or have no idea they affect website performance.

Honestly, @daigo75 points out quite clearly that a fix is like two minutes work, so why not fix!? I see the even old thread #400 has not been addressed either.

I for one am likely to avoid WP plugins that use Freemius in future as it just seems like bloatware to me.

[vovafeldman]

@skullo27 I wish it was as easy as setting the autoload to false - if that was the case we would have done that a long time ago. The thing is that we are storing all the settings in a single option record and some of the settings are required on every PHP load, so setting the autoload to false will not resolve it, the option will be loaded anyway but in a separate DB query (less performant).

[daigo75]

@vovafeldman Perhaps it could make sense to store the settings used at every page load separately from the ones used less frequently?

[vovafeldman]

That's the plan, @daigo75. To do so requires a full audit of the settings and making sure we don't break backward compatibility, it's a meaningful infrastructural change. We'll get there eventually.

[samuelbauer-io]

@vovafeldman 1,5 years later now - Update? Autoload 250kb in my case and that's really not what supports sustainable wp dev. Thanks for your understanding.

Possibility: The plugin "Admin Menu Editor Pro" does apply compression to it's autoload value (optional; can be activated in settings).

[vovafeldman]

@samuelbauer-io we are working on releasing a solution for it soon. You can follow the updates here #400