We have BB installed on Genesis child theme hosted on WP Engine.
We have had, for about a year, issues with CSS cacheing either being corrupt or 404s. How do we know? Testing.
We have screenshots and videos from users showing the CSS not loading on the site
We have have turned off any plugin that minimizes or caches files
We have disabled WP Engine CDN
We can download a page from the site and nail down the exact CSS file that would need to be missing or corrupt to display exactly has as it’s been documented by users. And that files is a BB file
We have searched through the logs and see 404s and find many references to some variation of the missing CSS in question. For example
By default themer clears the css cache once a month, in case you update any layouts… this will extend it to 6 months.
If your server cache is really aggressive and is caching your pages for over a month the css urls will become 404s …
Its either that or something is changing the pages layouts programmatically and not clearing the wpe cache when the layouts are updated so that could be causing the 404s
WP Engine has a 30 day cache, which to me sounds aggressive. I suppose I could also just write a script to clear out all cache every night from BB and WP Engine every night.
Is the BB cache clearing universal? Like does it clear all cache at the same time or is it individualized, based on the edit date of a template/module/etc.?
For this experiment to work, we need the cache to get generated and stop being re-generated without cause. If we are not editing the site, and if we the 6-month filter in place, we should see no new cache getting generated at some point, right?
Because we have a TON of new CSS cache in the last 24 hours. A ton of it. And on popular pages at that. So I’d think at some point we’d be fully cached and see no new cache.
Case in point… the Pricing page on our site. It’s obviously a heavily visited page. But we’ve made no edits. However, the cache for that page regenerates daily. It’s updated itself twice since we added the “6-month” suggestion.
There is no reason at all for this cache to regenerate so frequently.
The generated css for pages and layouts only gets deleted when the page or layout is edited, or the entire folder is deleted using the clear cache button in the backend.
The 6 month suggestion just means the bundle files wont self delete for 6 months… you can change it to infinity if you like and they will never self delete, again clearing the cache will delete all of them, editing the same layout will also delete them.
Disabling the cache clear tool just means that when you publish a page or post BB will not attempt to clear the cache for your hosting, in this case wpengine, which is a step backwards because WPE will still have the cached page and you just updated the layout so you are guaranteed to generate 404s that way.
We have no idea of what custom code you might have, we also have 1000s of WPE users with no issues whatsoever so there is no generic fix im afraid aside from disabling whatever custom code you have that keeps deleting the cached css and js files … maybe you have debug mode enabled?
What impact would debug mode have? It has been off but I did turn it on yesterday out of curiosity.
A perfect example of the issue: the pricing page has not been edited in a good 4 weeks. No one was in the admin editing any templates or pages yesterday. Yet the BB css for the page was updated. And we also had a report of that page showing to a user with no CSS.
Perhaps a better option is to just never delete any cache. Deleting it doesn’t guarantee a user sees new CSS if the HTML is still pointing to older CSS files.
Can I add a filter/action and disable all CSS deletes?
Gotcha. It’s off now. So we’ll go back to monitoring the CSS to see if/when it stops getting regenerated because it’s not supposed to be getting regenerated. And I’ll dig into the plugin and if there is no filter in place to prevent cache deletion, I will just flat out comment out the line that does the deleting. Because we would rather have too many old cache files than missing CSS for any page view, ever.
So wait you added the filter to keep the bundles for 6 months and after 3 days they were deleted?
Something or someone must be changing these layouts for them to be cleared like that. Have you looked at the simple history plugin?
Also I strongly suggest you dont edit core files unless you never want to update. We added a filesystem class for a reason
I wrote a POC plugin GitHub - Pross/bb-fast-filesystem
Deleted? Well, I’m working on validating that. But I can tell you that new CSS/JS cache is getting generated on pages that shouldn’t need it. Like I have a popular page that was last edited 7 days ago, but it got some new cached CSS/JS today.
As for editing the core plugin files… if there is another way to have the plugin not delete cache, I’m all for it. I’d rather users get old CSS than no css.
There are only two times css gets deleted, when a layout is updated or the cache clear button is clicked. Thats why I said to install simple history, it’ll tell you when layouts are updated.
If a page suddenly has a new css, then a layout or module was changed on that page, there is no other reason.