ghost
commented
4 years ago Hi @Shelob9, as mentioned here we're also having problems of high CPU and Database usage in our website. Logs mentioning problems in query like: UPDATEwp_optionsSEToption_value= '7' WHEREoption_name= 'CF_DB'
require('wp-blog-header.php'), require_once('wp-load.php'), require_once('wp-config.php'), require_once('wp-settings.php'), do_action('init'), WP_Hook->do_action, WP_Hook->apply_filters, Caldera_Forms::init_cf_internal, update_option, referer: http://ourwebsite.com/
Is there any problem with Caldera Forms? Thanks
Summarizing group ping in basecamp with @New0 and @kjohnson
In CF 1.8.0 we added an updater that clears all of the old wp cron events out:
https://github.com/CalderaWP/Caldera-Forms/commit/e7eb6de9f07c66bb5c7227aa5f2f03ddc850c876#diff-1bbcc95177f7c7b6efba1ba847387b6fR457
There can still be a lot of options in the options table leading to performance issues -- for example #3158 . SEE #916 for context.
We have this query here: https://github.com/CalderaWP/Caldera-Forms/blob/master/classes/transient.php#L166 So why don't we delete all of those on every plugin update to prevent too many options going in options table which is bad, as we recently found out?
Problem: We could loose transient data from a form submission that is in progress, which is bad. I would suggest versioning the prefix, though that means more complex queries.
DELETE WHERE LIKE cftransdata_%is not going to be too bad but,DELETE WHERE LIKE cftransdata_% AND WHERE NOT LIKE ...Shrug emojis.Or to summarize, can we run the query that @New0 manually ran today to fix the issue on CF.com on every plugin update? Because that would probably help a lot of sites.