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

CompressedManifestStaticFilesStorage equivalent outside Django #228

Closed
twosigmajab opened this issue Aug 13, 2019 · 5 comments
Closed

CompressedManifestStaticFilesStorage equivalent outside Django #228

twosigmajab opened this issue Aug 13, 2019 · 5 comments

Comments

@twosigmajab
Copy link

twosigmajab commented Aug 13, 2019

Currently the docs don't mention how to get equivalent functionality provided by CompressedManifestStaticFilesStorage outside Django.

If you might accept a PR adding something equivalent (at least for Flask?), you could also document a PRs welcome link to maybe get this added sooner.

Thanks for the great work on Whitenoise!

@twosigmajab twosigmajab changed the title using CompressedManifestStaticFilesStorage outside Django CompressedManifestStaticFilesStorage equivalent outside Django Aug 13, 2019
@evansd
Copy link
Owner

evansd commented Aug 14, 2019

CompressedManifestStaticFilesStorage is a plugin for Django's contrib.staticfiles system so it doesn't really make sense outside of Django.

If you want to create compressed files outside of Django then WhiteNoise already has a tool for that.

If you want to create files with unique names that can be cached forever (like Django's ManifestStaticFilesStorage does) then that's a bit more complicated as it will need to hook into the templating system of whatever framework you are using in order to make sure the right URLs get generated. I don't think it's possible to create a fully generic system for doing that.

Once you've generated the unique names, it's not too difficult to get WhiteNoise to send the right caching headers though. You just need to configure the immutable_file_test setting to mtach filenames with the right pattern.

@evansd
Copy link
Owner

evansd commented Aug 21, 2019

@twosigmajab As a general rule it's not a good idea to make significant edits to the title or description of an issue once there are replies. It makes it hard for other people to follow the discussion, and it doesn't trigger a notification to other participants in the thread that there's anything new to respond to.

@twosigmajab
Copy link
Author

I made the edits before there were any replies. I did that rather than creating a new ticket (with the more useful title and description) to reduce new ticket churn, which some maintainers prefer. In this case, I think GitHub should just send out an email notification when these are edited. In any case, thanks for telling me your preferences, will adhere to them going forward.

@twosigmajab
Copy link
Author

As for the actual issue, thanks for the helpful reply! I'll look into those pointers asap and post back here once I have.

@evansd
Copy link
Owner

evansd commented Aug 21, 2019

I made the edits before there were any replies

Ah, I see! I would have just read the text in the email notification and so wouldn't have seen the edits.

I guess it makes sense to edit the title so it's an accurate summary of the current topic of the issue (plus github makes it obvious in the UI how and when a title's been edited so it shouldn't confuse anyone too much). I would still avoid making large scale edits to comments though. Or at least, leave the original text but with strikethough.

Thanks

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants