silv3r.m00n

Hi

I have updated the widgets bundle on my site.
Its working good so far. The problem did not occur yet.

Thanks @misplon for the update.
I shall update SO widgets on my website and see how it works.

I guess you have removed the part where SO modifies the AO cache ?

Workaround: This is how i have fixed it for the time being

Edit the file : so-widgets-bundle/so-widgets-bundle.php

// EDITED: SILVER MOON
		if ( class_exists('autoptimizeMain', false) ) {
			add_filter( 'autoptimize_filter_css_exclude', array( $this, 'include_widgets_css_in_autoptimize'), 10, 2 );
			//add_action( 'siteorigin_widgets_stylesheet_added', array( $this, 'clear_autoptimize_cache' ) );
			//add_action( 'siteorigin_widgets_stylesheet_deleted', array( $this, 'clear_autoptimize_cache' ) );
		}

Disable the 2 lines registering calls to clear_autoptimize_cache

That will prevent abrupt deletion of AO cache by SO.

@optimizingmatters i have been able to reproduce the problem partly.
And it seems to be caused by Siteorigins page builder.

Here is how it works.

So lets say there are 10 siteorigins built page on a website.

If a visitor accesses an OLD page say P7 which was not already cached by AO, the page will load, but it will cause cache (css files) of other pages to be deleted from AO cache directory.

Now those other pages that are being served by WP Fastest Cache are referring to deleted css files and render incorrectly.

Siteorigins need to be careful when trying to delete AO cache,
OR it should not try to do it at all.

Or may be give us an option to turn this feature ON/OFF from admin panel.

Thanks for the quick reply.

If AO does not purge its own cache, that solves half the problem.

So I ran the grep command and found something.

plugins/so-widgets-bundle/so-widgets-bundle.php: if ( class_exists(‘autoptimizeMain’, false) ) {
plugins/so-widgets-bundle/so-widgets-bundle.php: add_filter( ‘autoptimize_filter_css_exclude’, array( $this, ‘include_widgets_css_in_autoptimize’), 10, 2 );
plugins/so-widgets-bundle/so-widgets-bundle.php: add_action( ‘siteorigin_widgets_stylesheet_added’, array( $this, ‘clear_autoptimize_cache’ ) );
plugins/so-widgets-bundle/so-widgets-bundle.php: add_action( ‘siteorigin_widgets_stylesheet_deleted’, array( $this, ‘clear_autoptimize_cache’ ) );
plugins/so-widgets-bundle/so-widgets-bundle.php: public function include_widgets_css_in_autoptimize( $excluded, $content ) {
plugins/so-widgets-bundle/so-widgets-bundle.php: public function clear_autoptimize_cache() {
plugins/so-widgets-bundle/so-widgets-bundle.php: if ( class_exists( ‘autoptimizeCache’ ) ) {
plugins/so-widgets-bundle/so-widgets-bundle.php: autoptimizeCache::clearall();

plugins/smart-slider-3/nextend/wordpress/assetInjector.php: add_filter(‘autoptimize_filter_html_before_minify’, array(

plugins/popup-builder/readme.txt:* Tweak: added compatibility with autoptimize plugin.

*********

There are 3 plugins with mention of AO. The popup-builder just mentions the name and nothing else.

What do you think about the output ?

I also installed the wp control plugin to see what is running via cron. This line caught my attention

ao_cachechecker None
autoptimizeCacheChecker->cronjob()

It seems to come from AO. What does it do ?

I faced the same problem on my site. Server load shot up, memory and cpu usage at peak. Disqus plugin version 2.84

Nginx log file filled with errors like these

***
016/02/15 17:16:32 [error] 12373#0: *1468425 FastCGI sent in stderr: “PHP message: WordPress database error Lost connection to MySQL server during query for query UPDATE wp_options SET option_value
***

The value of cron option in wp_options bloated up to 400KB. The cronjobs array in options table was filled with “dsq_sync_forum” for thousands of times.

1. So disabled Disqus comments.
2. And cleared the cron value using the sql query –
UPDATE wp_options SET option_value = ” WHERE option_name = ‘cron’