Cached CSS file gets deleted at Midnight

Morning silv3rm00n;
AO does not have a cache purging mechanism, in part exactly to avoid the kind or problem you’re facing (other reasons here).

And yes, this could be due to some other plugin, I know e.g. Divi purges the AO cache (too) regularly, but any plugin (or theme) could either by calling autoptimizeCache::clearall() or (worse) by doing a filesystem delete of wp-content/cache/autoptimize or wp-content/cache/.

Can be hard to identify what/ who is doing this, I think “easiest” way would be to log into your server (SSH) and in wp-content use grep -r autoptimize * to find any file that mentions autoptimize?

hope this helps,
frank

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 ?

re autoptimizeCacheChecker->cronjob() it’s a daily job to see if cache size went beyond the 0.5GB threshold, in which case a warning mail is sent and a notice is shown on the dashboard.

but this could be the one:

plugins/so-widgets-bundle/so-widgets-bundle.php: autoptimizeCache::clearall();

@misplon does siteorigin widgets indeed trigger AO cacheclear round midnight?

frank

Hi Frank, I’ll chat with Braam who did the integration work and come back to you on this. Thanks.

@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.

good job @silv3rm00n , I’m sure Siteorigins (Braam) will be able to help! ??

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.

Hi guys, just an update on where are at the moment:

* When a Widget Bundle widget’s CSS changes we need to let AO know, so it can regenerate minified files.
* The only way we could see to do this was to clear AO cache.
* Third party caching plugins which aren’t listening for the AO autoptimize_action_cachepurged action, will continue trying to serve files which have been deleted.

There isn’t any mention of autoptimize_action_cachepurged in WP Fastest Cache. We’re currently discussing possible ways forward. Our resources are limited which reduces the possible routes we can take. We could definitely add a filter to disable our AO cache clearing. I’ll update you as I know more. If WP Fastest Cache supported autoptimize_action_cachepurged, that would solve this specific plugin combination.

When a Widget Bundle widget’s CSS changes we need to let AO know, so it can regenerate minified files.

well, actually AO “knows” as getting HTML to optimize it aggregates what it is configured to aggregate and makes md5-hash of the string of aggregated unminified CSS. if the CSS is different, the hash is different and the fetch from cache will fail, triggering a new cache entry being made with the minified version of that code ??

Super, thanks for the help ?? We’ll push a release ASAP later this week with the fix.

going to mark as resolved as not AO proper, but feel free to follow up here anyway ??

Thanks ??

(Will update when SO Widgets Bundle is updated this week.)

Hi ?? The Widgets Bundle has been updated. @silv3rm00n, hopefully, the update helps. If you have a moment this week, perhaps you could let us know how it goes on your end. Thanks.

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 ?

Super, thanks.

That part was removed indeed. The commit can be found here.