We did add the plugin and we are monitoring it. Last night, for example, the plugin generated a lot of updated CSS files and a handful of of the more transient CSS cache files. And it’s on pages that no one touched. It was, after all, the middle of the night. Anyhow, we’ll keep an eye on that.
I think what I’ll do next is add in logging on the CSS delete calls. I already hacked it to not delete, so I might as well try logging those calls from that same location.
Perhaps a log of the calls to delete CSS cache will help track down the cause.
well if you have deleted the files… and then they magically appear… that means the page was accessed by a visiter and the plugin generated the css files for the page.
Turns out what we have going on is not a cache delete, but rather a case of BB generating and serving CSS reference through HTML BEFORE the CSS file is generated.
I have multiple log files showing the 404 for the CSS 1 second before the CSS file is created. I have seen these since I started researching the issue but thought I was just mis-reading it. I am not. It’s 100% validated by multiple people on our team.
If you have the same issue, try the same resolution and use the inline assets filter. Double caching will always create issues. Choose one cache or the other, I bet you host is adding caching too.
