While solving my various noob problems when creating my own theme (some on my own and some with your help, thx for that), I found what appears to me as a misbehaviour in “hugo serve”.
I use a static css:
themes/first/static/css/style.css
Somehow updating the browser-cache on this does seem to fail:
Immediately after saving a change it gets reflected in the browser … brillant.
But when reloading the browser-page or following a link to another, the magic is gone and the previous version of style.css is being used from some browser-cache. And the browser cannot be convinced to reload with the new style.
Deleting the last-hours browser-cache actually plays the trick: then all is actual.
But honestly: is this meant to be like this? Before I try an HTTP trace and inspect cache headers and that stuff, I thought I asked if this is a traditional issue…
The common pattern is to somehow turn it off during development, and make sure you control it when going live (for example by fingerprinting your CSS etc.).
For development there are (at least) 2 options:
My recommendation: Work with the Chrome dev tool open with the cache disabled (this is default)
Run server with --noHTTPCache. But note that I recommend/like 1) better, as Chrome seem to be smarter about it. 2) Seems to slow things down.
Ok, basically your answer solved my problem. Nevertheless a question remains.
I do have two viable options to go on. Actually using the devtools of the browser (chrome, ff, ie, they all have this stuff now, I am a chrome-fan) should have come to my mind immediately. I claim to be busy and distracted ;-).
I have checked the livereload code. What I do not get is why - with cache enabled, the reload mechanism works for the content and theme files but not for the static files like my CSS file?
That is by design. The file did not change, so the browser is not loading it new. That is basically what Hugo is doing: Speeding up your website
When you change page X, but the file you load from page X (like style.css) is not changed in it’s content (a space would be enough if you don’t minify), then the browser sees, it’s not bigger, smaller, the ETag header is the same. So the browser decides to cache. File date is nothing to your browser. And: Your browser is stupid, it does not know that your site is running on a development machine.
Chrome devtools does the trick, there is no way (yet?) to add headers to the hugo server command (and it would probably distract from more important features to implement).
I remember there being a CLI parameter for the server command that reuploads ALL static files on changes - maybe try that one? But the way I experienced browsers they don’t care much about file dates.
And the content files - they reload because of the live-reload function that is loaded with those html-pages. Thats not available for static files like images and such.
If anybody (like me) comes across looking for a solution: like @bep wrote, the browser cache can be disabled in developer tools:
With that option, the CSS renders fine on any change.
I just came upon this issue while following the tutorial in the Build Websites with Hugo book and using Hugo’s internal server.
I tracked it down to Firefox not accepting a cache update for css/style.css
As per the original poster, koffeiniker, it does transfer an updated css/style.css file and incorporate the changes on the current page, but when you move to another page in site, the updated css/style.css is lost. I am able to change this behavior by selecting Disable HTTP Cache (when toolbox is open) in Settings.
The interesting point is: For Chrome and Safari, I did not need to disable caching in any way for the page to use the same updated css/style.css file!
BTW, I checked and Chrome has two places to disable caching, first under the Network tab as el_simon points out, and in the Settings with Disable cache (while DevTools is open). Neither were checked for me, and still the cache was updated.
For me, this started out looking like a Firefox problem. Now I am wondering why Chrome and Safari don’t work like Firefox.
