Support » Plugin: Booster for WooCommerce » 1250 option fields???

  • I was freaking out while trying to find out the cause to an “initial” slow page load after I don’t visit my page for a couple of hours. I installed the “Query Monitor” plugin to see what was causing this nonsense, and saw that there was this huge (required) query for wp_load_alloptions() which loaded close to 2000 fields from the wp_options table.

    I thought “yeah sure, I tried out a dozen plugins that I don’t use now, those plugins’ orphaned option fields should be the cause”. Yet when I opened phpMyAdmin and clicked wp_options, my jaw dropped as I saw more than half of those fields started with wcj_... which are the initials of this plugin (WooCommerce Jetpack)!

    I like your plugin very, very much, but please do something about this. Most of those fields could be serialized and grouped together as one field. You could potentially reduce the number of these fields down to ~100. Please please please do something about this!

Viewing 5 replies - 1 through 5 (of 5 total)
  • One more thing: I’m using only a few of the Booster modules, yet all settings of all modules are saved to the database with their default values. And if you intend to fix this, you should also add a tool to the Booster Tools page to cleanup unused settings.

    Last suggestion: The “settings exporter” tool neatly crunches all settings into a single, small file with serialized settings. I’m not an expert but can you save the fields to the database like the export file? In my example, my settings export file takes up ~100KB of space. When you load this as 1250 different queries, it’s slower, but one single query of 100KB wouldn’t be too hard on the server.

    …hello? Anyone there?

    Plugin Author Algoritmika Ltd



    Sorry for such a delayed reply. I will definetely think this through, however I must say that Booster handles the options exactly as WooCommerce does. Unfortunately now number of Booster’s options exceeds the number of WooCommerce options (I didn’t thought about it when started developing the plugin, when we only had a couple of modules with low number of options).

    Best regards,

    you could (should) at least group the module options in single, serialized DB fields. And maybe not “autoload” them even when the modules are inactive. I really like this plugin, I even thought purchasing it & translating it but seriously, it has sooo much load on server resources.

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘1250 option fields???’ is closed to new replies.