-
-
Notifications
You must be signed in to change notification settings - Fork 498
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
using sorl-thumbnail and easy-thumbnails side-by-side #445
Comments
@mariocesar If we were to provide a PR for such a change, would you merge it? |
@stefanfoulis Sure |
Either, will be good to have an |
👍 |
For anyone coming across this post, this works for me in the meantime: https://stackoverflow.com/a/35166302/396300 with the caveat that you can only use one library on a particular template. |
Thanks to this file https://github.com/jazzband/sorl-thumbnail/blob/master/sorl/thumbnail/templatetags/sorl_thumbnail.py , it is now possible to use I don't think the remaining conflicts have been fixed, though. |
easy-thumbnails now also provides alias {% load easy_thumbnails_tags %} , which solves the conflict on the other side too. I believe this ticket can be closed now. |
It would be really useful to be able to use both
easy-thumbnails
andsorl-thumbnail
in the same django project. 3rd-party apps may depend on one or the other and currently it is just impossible to install both into the same project.As far as I can tell the only reason the two don't work together is because of variable name clashes.
Is this something both projects would consider addressing?
Problem: both libraries use the same names for things
In templates:
And in settings.py both use the same
THUMBNAIL_
prefix:Suggested way to make both play nice together
My suggestion would be that both libraries switch to prefixing their settings uniquely:
For the transition both libraries could add a setting:
That reads the settings with the new prefix and outputs a deprecation warning if not set to
True
.After a few releases the default could be set to
True
.Similarly for the templatetags. Both libraries could change the templatetags to use the prefix:
Both libraries would keep the
thumbnails
version around, but it would issue a deprecation warning. If both are installed in the same project, the one first inINSTALLED_APPS
would be used when using the old name.The text was updated successfully, but these errors were encountered: