Reduce the number of options in the database

[jdevalk]

I want to suggest using 1 option for the plugin with a keyed array in it, instead of the gigantic number of options that you're adding to a site now. I recently had to clean up a site that had use this plugin and I was a tad bit annoyed by the sheer number of options in the database.

[Saggre]

That would make WP-CLI's wp option commands not practical to use with the plugin though

[hi-hai]

Also it will cause potential plugin upgrade issue. Won't consider this feature.

[jdevalk]

I’m sorry but those are both nonsensical arguments.

WP CLI has a pluck option for this:

wp-cli/entity-command#106

and upgrade you can just write an upgrade function for.

[justlevine]

Disappointed to see this closed so quickly and seemingly without much consideration (LSCache has included upgrade functions that alter the db structure in the past).

From an extender POV, the settings storage impact performance and hurt DX (although WP's new get_options() help a bit. It's also significantly more scalable (less code for us to (re)do when new settings are added).

The options also don't necessarily need to be collapsed into a single setting; a handful of hinted arrays to track would still be a huge DX improvements over the hundred+ that we have currently.

[hi-hai]

Sorry for the quick answer previously. I apologize if the wording made you feel offended. I didn't intend to be like that. Thanks for the feedback. We are always open to suggestions and want to keep improving our plugin.

There is a long and complex history behind our choice to use separate entries per option (WooCommerce and some other plugins do the same way), and it would not be trivial to change it now.

If the issue is performance concerns, I think improving business logic has a better chance of speeding up WP than changing the way we deal with options.

We purposely leave the options behind when the plugin is disabled, in case the user is disabling it temporarily. Otherwise, their fine-tuned options will be lost. If the issue is database cleanup, would it help if we provided an option to remove this information from the database upon uninstallation of the plugin?

Sincerely,
Hai

[Mte90]

It isn't only an issue to remove the option when the plugin is removed.
Woocommerce saves too options in the DB, but they aren't loaded in all the pages but based on the context. Considering that for the same performance reasons they created their own DB tables of the various data...
As we are talking about a plugin that improve the performance, caching and so on this means that there is a query to get all the options or more query to get every single option.
As we are talking about performances, having multiple entries in the db for different settings is not so much performance savy...

Also I didn't checked but those options are in autoload in wp_options? Otherwise they are loaded in every single page including admin...

[pbearne]

This an example why the ticket not autoload options by default is way to go

[GermanKiwi]

We purposely leave the options behind when the plugin is disabled, in case the user is disabling it temporarily. Otherwise, their fine-tuned options will be lost. If the issue is database cleanup, would it help if we provided an option to remove this information from the database upon uninstallation of the plugin?

Keeping the options when the plugin is simply disabled is fine, but there definitely should be a user setting to delete this information from the database upon uninstallation. Adding this setting would help.

Even if it isn't trivial to change how the options are stored currently, perhaps it's still something you could work towards changing in the future, as a longer-term goal?

And hopefully the options are not all loaded with every single page, including admin, as @Mte90 mentioned...

[hi-hai]

Good to know. Thanks for your feedback. Will take into consideration.