Broken pages after some time (css and js error 404)

Check that you don’t have the “Purge Minified CSS/JS files instantly” option enabled.

The cache is no longer automatically deleted.

If the above option is not enabled, it will only delete files that are at least 24h, at the moment of cache purging. There is no longer a cronjob to delete them on the background, so they should remain there at least until the next manual cache purge, or whenever there is some action triggering it.

If you use nginx fastcgi cache, install the nginx helper plugin.
FVM supports it and it can purge your page cache when needed.

Alternatively, you can also create a location block and add it to the fastcgi cache, possibly with a higher TTL. Static files can also be cached in RAM.

Hi there, sorry for bringing this up again but I have the same issue and wondering about your solution.

For instance a client visited the page a week ago. I changed some styling, the browser tries to access the css which doesn’t exist anymore and the client sees a broken page while waiting endlessly. Quite bad.
I wonder why no ?version is added to the filesnames so the next request by the browser gets a hint to re-download the new css version?

Maybe I get it wrong but there is missing a notice to the browser, (isn’t it called Cache-Busting?), that the CSS/JS file changed because in my case I don’t need to have expires header of a day.

• This reply was modified 3 years, 5 months ago by mike8040.

Hi Mike,

It depends of what kind of caching setup you got.
If you use the caching plugin supported by FVM than I think FVM will initiate the cache purge when new CSS/JS files are generated.

For @alignak:

Nginx helper plugin would probably solve my problem but I don’t want FVM to purge my cache because we use background update for content refresh.
I think the problem is that some of my pages are cached a bit later and that they use already generated FVM JS/CSS files that get deleted before the actual pages expire.
One solution would be to reduce the cache expiration from 24h to 12h so that we never have deleted FVM files.

Is there a way to extend FVM files purging time?
Can I add something to functions.php to achieve this?

@mike8040 if you change some css file, you must purge all caches, always, regardless of using FVM or not, else you won’t see those changes consistently.

Files don’t require a query string. Query strings should not exist on static files.
If the file contents changed, FVM will rename it differently. The filename, is an hash of the code it was merged. But the minification is cached, to speed things up, that is why you need to purge the caches after modifying files.

The file renaming, is already the cache busting mechanism.

What problem exactly are you facing?
It sounds like you simply did no purge the caches properly.

—

@devopti the files are not deleted after 24 hours. If you don’t have the immediate purge enabled, it will only delete files older than 24h, at the time of the purge.

Minified files are static files with dynamic url’s, which may disappear anytime.
FVM needs to be able to purge the page cache, else your page caching is pointing to the wrong files. Whenever there is a FVM cache purge, you need to purge the HTML cache globally.

If you wan to increase the limit, then you can edit the functions.php file on line 540 and replace 86400 with the desired amount of seconds.

But hold on for that, there will be an update in a few days and I will extend this to 7 days for broader compatibility.

Hey Raul,

thanks for your reply. I know about the importance of purging and do it regularly. THe issues I have is with the clients browser cache. I have several mobile devices to test sites. If I kept a page in a browser tab and open the browser again some days later, the browser refreshes the page (device related ram refresh), but he doesn’t seem to find the style files then and the user sees a broken layout. I need to refresh the page manually to get a working layout again. This is obviously a bad user experience to clients and indicates the cache busting I referring to.
The same happened also on desktop browsers where I opened the pages through googles search results, where the browser had cache for the site stored from a previous visit and seem to not get an info about a newer style version and threw out a 404 error for the css files.

I set the expire header for css to a day to counter that behavior for now but it shouldn’t be necessary. So I’m trying to find a way to force the browser to check the file version/file name. I’m quite lost here because on other pages I’ve done in the past where I was working with Auto-optimize I never run into such issues.

• This reply was modified 3 years, 5 months ago by mike8040.
• This reply was modified 3 years, 5 months ago by mike8040.

@alignak

Thank you for the help.
I will wait for the update. ??

One additional question:
Does CSS Processing takes and minifies inline CSS from the pages?
I’m asking because CSS class for some elements gets randomized on every refresh and because of that inline CSS changes too (Flatsome theme).