-
Posts
-
Hi!
We’re having into some issues with the server on our site running Enfold.
The issue is our wp_options table with autoload = yes rows is over 3MB.
Hundreds of thousands of these autoload yes rows are from Avia Builder. These are the results of the query with number of rows per key:
355000 aviaAsset_css_filecontent
92754 aviaAsset_js_filecontent
34933 av_alb_usage_av_textblock
32707 av_alb_usage_av_heading
32547 av_alb_usage_av_one_third
32493 av_alb_usage_av_two_third
32492 av_alb_usage_av_video
11611 avia_options_enfold_childCould you offer some guidance as to which rows are needed and which are old, deprecated or can be removed?
Thank you
Hey SCMHR_HomeOffice,
Here is an article for you
If you need further assistance please let us know.
Best regards,
VictoriaHi Victoria,
That is a great article, one that I’m familiar with. I am not asking how to delete rows in the db.
I’m asking specifically about the thousands of autoload yes options added by Enfold to the db.
My question to you guys as developers of Enfold is if we can delete these or if doing so will cause issues, visible or otherwise, in our site?Hi again,
My apologies, I was misunderstanding our problem. My question is now limited to just a yes or no answer to the question:
Can I expect functionality issues from setting the following wp_options registries to autoload = no?:
av_alb_usage_av_textblock
av_alb_usage_av_heading
av_alb_usage_av_one_third
av_alb_usage_av_two_third
av_alb_usage_av_videoThank you
Hi,
Thank you for using Enfold.
av_alb_usage_ is needed when using Performance -> Disabling of template builder elements -> Load only used elements.
Not sure, why you have so many entries – actually there should be only one for each ALB element.
You can set it to “no” and check, if it has a negative effect on page loading speed. From functionality it should not make any problems if the options are loaded seperatly when needed.
Best regards,
GünterHi SCMHR_HomeOffice,
Glad you got it working for you! :)
If you need further assistance please let us know.
Best regards,
VictoriaWhile optimizing site speed I ran into the same issue. Enfold by far is the biggest wp_options polluter, resulting in a size of 4.6MB !
The css and js data should NOT be stored in wp_options, it’s not designed for that and slows everything down. A quote from a database specialist:
When a WordPress page loads, it runs this query every single time:
SELECT * FROM wp_options WHERE autoload = ‘yes’
If the wp_options table is larger than 1MB in size this query results in rather heavy database use, which means you should try to clean up the wp_options table.To find the rows with the largest amount of data in the option_value field, use the query:
SELECT option_name, length(option_value) FROM wp_options WHERE autoload=’yes’ ORDER BY length(option_value) DESC LIMIT 30
If you find plugins that are polluting the options table with unnecessarily large rows, we recommend you to file a bug report with the plugin’s author.Tip #4 https://seravo.com/blog/13-tips-for-a-secure-efficient-wordpress-database/
Hi,
Thanks for the info.
The database entries where the theme stores the compressed css and js code are not required every time a page is loaded. They are only fetched if the merge scripts or stylsheets do not exist or have to be regenerated. You can install the Query Monitor plugin to confirm that.
Best regards,
IsmaelThanks but I would still prefer a smaller wp_options table. Seems more appropriate to have its own table.
@Ismael, what is the progress with this. If your wordpress developers haven’t replied by now, and there isn’t a fix in place, then they do not know what they are doing. ezFl0w is completely correct.
This is a serious issue, the wp_options table should not be used for this sort of purpose.
- You must be logged in to reply to this topic.