Caching a seeing changes made

[rcane]

Making a duplicate forum. 
2.0.19 and ants mutant.

 I set the new one to no caching since it's just me setting it up, so I can see changes in layout right away (changed a color).

The changes won't appear on any browser once made and refreshed.  It's as if it's waiting for cookies to expire. 

They reflect fine when changes are made to site 1.

[Arantor]

No, they don't. The caching settings inside the forum settings are absolutely nothing to do with layout changes being cached by your browser. The caching being done are literally on two different computers.

Caching in the SMF settings is for things like the list of recent posts on the front page, it gets the list and stores it on the server so it's ready-made rather than having to figure it out the next time.

The CSS on the other hand is cached by your computer. That said, it's possible for other things between SMF and your computer to cache them - whether that's your server using something like Varnish (ask your host; but doubtful since you've not reported any of the other symptoms typical with Varnish) or CloudFlare (you'd have had to set this up yourself in most cases) which cache it between SMF and your computer. However SMF's settings do *not* affect this.

What's more likely is that your browser is holding a cache and that when you happen to have the inspector open, it's more likely to drop the cache (unless you go to the Network tab and explicitly tick disable cache) and refresh. Chrome in particular is very awful about this. I find the only real choice for Chrome is to have the inspector open, make sure 'disable cache' is ticked and then often have to Ctrl-F5 since regular refresh isn't always enough.

I'd like to suggest SMF 3.0 (or whatever the one after 2.1 is) takes a different approach where this can be better managed inside SMF; it's completely doable to make this work in such a way to avoid any caching problems and push new versions of CSS automatically on demand, but it requires some serious design work to implement properly.

[Sir Osis of Liver]

I've used this in .htaccess to address this problem.  It's quite old and may not work, but no harm to try it -

Code Select Expand


# NEVER CACHE
<FilesMatch "\.(txt|htm|html|php|css)$">
Header set Cache-Control "max-age=0, private, no-store, no-cache, must-revalidate"
</FilesMatch>



[rcane]

I've used this in .htaccess to address this problem.  It's quite old and may not work, but no harm to try it -

Code Select Expand


# NEVER CACHE
<FilesMatch "\.(txt|htm|html|php|css)$">
Header set Cache-Control "max-age=0, private, no-store, no-cache, must-revalidate"
</FilesMatch>



That's clever.  Thanks.

[Arantor]

Except it's really not because now you consume more bandwidth than necessary sending it every single time regardless of if there are changes and it makes your site provably slower (and actually has an SEO penalty in Google)

The '|css' part should be taken out of that expression.

But then again, the correct approach isn't to make changes directly in production but to do it offline, figure out all the problems in it then push it once to production where there are other, better, ways to handle cache busting.

[Sir Osis of Liver]

Well, now you're just being fussy.    Most forums don't have nearly enough traffic to make bandwidth a problem.  Same with disabling forum caching, I've never seen any noticeable difference in performance.  As for |css, it does no harm being there, and I did mention this is an old trick.  You might recall that 1.1 had style.css theme files. 

Some older versions of IE would hang on tenaciously to cached files, especially images and css.  Sometimes you couldn't see changes til next day.

[Arantor]

Of course I remember 1.1 having such things. I also remember that 1.1 predated Chrome by several years and that Chrome wasn't as enthusiastic about caching then as it is now.

I also wouldn't make the assumptions you make about "traffic", because search engines these days go get style information...

[Sir Osis of Liver]

<Fussy bugger.>