Crashes WordPress, Maximum Memory Exceeded in Options.php

Sorry, this script will work better.

DELETE wp_options FROM wp_options INNER JOIN (SELECT option_name FROM wp_options WHERE option_value = “a:0:{}” OR option_value IS NULL OR option_value = “”) AS opt2 ON opt2.option_name = wp_options.option_name

It appears the above script is not going to work.

These are the lines that are bringing down our site. Essential Addons for Elementor-light\Traits\Generator.php

// update page data
update_option($this->uid . ‘_elements’, $this->loaded_elements);
update_option($this->uid . ‘_custom_js’, $this->custom_js_strings);
update_option($this->uid . ‘_updated_at’, get_option(‘eael_editor_updated_at’));

The Second Post, Last Delete with Option_name has brought the site up. But there are hundreds of _created_at’s, that look orphined and undcared for in here as well.

This is NOT the way to use the Options table. Please fix this immediately, as this table has ALL its values loaded in memory on EVERY page load. And when you consider each post is 3 rows, AND that its not being maintained, AND that it contains Empty values and orphaned values… It’s not good. Atleast use Transiants. Or better yet, create a new table for them.

Hi @mgparisi,

I hope you are doing well. Thank you for your detailed report. Anyways, we do already have a plan to work on it to reduce the data in options table. Since it’s a complex issue, it might take a bit of time for this to deployed.

I hope you understand. Thank you!

Please respond, this plugin is bringing down my clients site!

We have 625865 records, and its using all of the data with the created_at’s, Its also now exceeding 1 GB in size, and is exceeding the size capacity of our host. And this plugin is the ONLY one causing it.

This is not a complicated issue. This is NOT how you use the options.

Create a table, and use it instead of using these options above!

• This reply was modified 3 years, 10 months ago by Michael.

Hi @mgparisi,

I hope you are doing well. We have pushed a new update today (4.8.0) which addresses the options table issue and have reduced data in the options table for better performance. So, the issue you have mentioned should be all good now.

Can you please update to the latest version and check back? Let me know how it goes.

Thank you!

Ok, we will upgrade. We had setup an automated delete to delete all options with an empty json value or just an empty value. Which worked very well. All that had to happen was a check to see if the value (or JSON) was empty.

And THANK YOU! This was a very bad bug!

• This reply was modified 3 years, 8 months ago by Michael.

It didn’t crash the site, and upgraded well. I didn’t check if the empty values exist, but I trust you and your fix. I’ve changed the review I left as well, and mentioned the good support. My change to the review didn’t seem to get saved, so it might need to be approved. In a few days I will try to check it again to make sure its submitted. Glad to see you fix it.

++Good Support

• This reply was modified 3 years, 8 months ago by Michael.
• This reply was modified 3 years, 8 months ago by Michael.
• This reply was modified 3 years, 8 months ago by Michael.

Hi @mgparisi,

Glad to know that your issue has been resolved now. The review hasn’t been changed yet. Can you please check that here

We would really appreciate it if you change this. Thank you so much.

Hello @rafinkhan

Good afternoon.

My site is down again. Filled with “updated_at” options from your plugin for one value. One after another is beign added, and we now have 200,000 rows in the options table.

It also is still filling values of created_at and others.

Can you not add some logic that won’t update the option if it contains an empty, and the json equivalent of an empty value. I’ve not experienced any issue from removing these.

• This reply was modified 3 years, 8 months ago by Michael.

`We need also help this situation not ok
as match as we love the plugin (pro version)
The options and value table are growing on every post, and it’s impossible to control.
1. I’m sure the ‘autoload’ option should be false most of the time (why every section is yes). It’s slow the request on every page.
2. If you need to save so match data, use a separate table that can be optimized to better SQL that we can optimize for one of the memory access (Memcached and Redis )
3. leave options table alone. It’s not the place to store every single post info.

Can we change all ????????_updated_at to autoload = no?

we have over 28884 of them

Hi @101sam,

Actually, we have set autoload as false by default in our plugin. Anyways, you can set it as no and it won’t be a problem.

Besides, thanks for your suggestion regarding creating a separate table but it would be very hasslesome to maintain it.

Thank you!