Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add Cache-Breaking to static resources #777

Closed
neos-bot opened this issue Mar 5, 2015 · 15 comments
Closed

Add Cache-Breaking to static resources #777

neos-bot opened this issue Mar 5, 2015 · 15 comments

Comments

@neos-bot
Copy link
Contributor

@neos-bot neos-bot commented Mar 5, 2015

Jira issue originally created by user mrimann:

It was lately discussed multiple times on Slack, how to make sure that static asset files like CSS or JS files are prevented to reside in the Browser-Cache upon having a new version of the file on the server.

Several possibilities have been collected:

It seems that the variant with the Resource-Viewhelper was preferred by some of the developers - now the proposal is to directly add that to the Viewhelper itself as an optional feature, see https://typo3.slack.com/archives/typo3-neos/p1425583562000729

Jira-URL: https://jira.neos.io/browse/NEOS-1063

@dimaip
Copy link
Member

@dimaip dimaip commented Nov 3, 2016

I propose to add cachebreaker (name to be discussed) parameter to ResourceUri Fusion object and Fluid VH. The best way to generate that cache breaker is via md5_file I believe, as modification time can't always be trusted, since it may change on deployment.

@kitsunet
Copy link
Member

@kitsunet kitsunet commented Nov 3, 2016

I don't understand what speaks against the external solution (could even be a separate VH to calculate the md5_file)

@kitsunet
Copy link
Member

@kitsunet kitsunet commented Nov 3, 2016

I am not too resistant to add it though...

@dimaip
Copy link
Member

@dimaip dimaip commented Nov 3, 2016

@kitsunet I think it's a common enough requirement. Maintaining a pair of VH helper/Fusion object is a bit annoying, I'd rather use a native API.
Just one of those little things that make a life of an integrator easier.

@kdambekalns
Copy link
Member

@kdambekalns kdambekalns commented Nov 3, 2016

IMHO this should be taken care of by the server setup. E-Tag & friends… Appending some "garbage" to the URL is not the best way to solve this, IMHO.

@bwaidelich
Copy link
Member

@bwaidelich bwaidelich commented Nov 3, 2016

I second @kdambekalns' opinion (even though I supported the idea back then apparently ;)

@dimaip
Copy link
Member

@dimaip dimaip commented Nov 3, 2016

Thanks for your thoughts. Since E-tag is a preferred solution, let's leave it up to a 3rd-party package if one really needs it.

@dimaip dimaip closed this Nov 3, 2016
@mrimann
Copy link

@mrimann mrimann commented Feb 21, 2017

Thanks to @dimaip there is now a 3rd-party package if someone is interested: https://packagist.org/packages/opsdev/cache-breaker

@aertmann
Copy link
Collaborator

@aertmann aertmann commented Feb 22, 2017

It's still a useful feature for those who don't know how to or are restricted in adding proper E-Tags, but keeping it as an external package makes sense.

We have actually needed it in Neos because we can't rely on users using proper E-Tags, but I guess we can create our own helper for it too.

@dimaip
Copy link
Member

@dimaip dimaip commented Mar 21, 2017

I read up on the subject and spoke with a few clients who are deep into this stuff, and they all reject using E-Tags as being slow and requiring extra request. Besides, E-Tags never worked reliably for me, where some resources would get stalled (I do have them set up correctly).
I would propose to eventually include this cache breaker thing in the core.

@dimaip dimaip reopened this Mar 21, 2017
@daniellienert
Copy link
Member

@daniellienert daniellienert commented Mar 21, 2017

Have the same problem right now. Thanks @mrimann for the package.
👍 to @dimaip to make that a core functionality.

@rolandschuetz
Copy link
Contributor

@rolandschuetz rolandschuetz commented Sep 21, 2017

FlowPack also provides a package for this no:
https://github.com/Flowpack/Flowpack.CacheBuster

@jonnitto
Copy link
Member

@jonnitto jonnitto commented May 3, 2018

So, what will we do? Will we add this to the core or give the advice to use the Flowpack.CacheBuster?

@dimaip
Copy link
Member

@dimaip dimaip commented May 3, 2018

I still hold up to what I said in the comment above, but would not object to any alternative solution.

@Sebobo
Copy link
Member

@Sebobo Sebobo commented Oct 23, 2018

I'll close this for now as the flowpack cache buster package takes care of it and people can customize it to their needs.

@Sebobo Sebobo closed this Oct 23, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet