-
-
Notifications
You must be signed in to change notification settings - Fork 200
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
Enhance Thumbnail Functionality #304
Enhance Thumbnail Functionality #304
Conversation
Adding proper Python specifications for Pillow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Super thanks for a great contribg!
My suggestion would be to default to sorl for a while, as it is not 'broken' anymore, and this is what all users are using right now. However, we should yield a deprecation error when no thumbnailing is explicitly configured - and we might add a no-op thumbnailer for users which don't want to use any kind of thumbnailer.
Once more, GREAT WORK! It's a pleasure to review such a great piece of code. Sorry it took a while to get to it!
.travis.yml
Outdated
@@ -39,8 +39,6 @@ install: | |||
# Latest PIP uses wheel by default | |||
- pip install --upgrade pip | |||
- pip install $DJANGO | |||
- pip install -r requirements.txt | |||
- pip install -r requirements_test.txt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why are these removed?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe this was because I was noticing some odd behaviour in testing. I unfortunately cannot recall exactly what was happening, but I believe I was getting tests that passed locally with the setup.py test
command, but then failing in Travis-CI. Removing these lines resolved the issue and all other tests continue to pass. My Travis-CI history unfortunately has since removed the offending tests from the history.
If I were to make an educated guess, I think we were getting weird version conflicts because we install these packages into the environment and then install things again with the setup.py test
command.
If we need a definitive answer I can add the lines back and see what happens in testing!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer you take this file straight from master, where CI seems working just fine. :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated with requested changes.
newsletter/admin.py
Outdated
models.TextField: {'widget': newsletter_settings.RICHTEXT_WIDGET}, | ||
} | ||
|
||
# https://easy-thumbnails.readthedocs.io/en/latest/usage/#forms | ||
if newsletter_settings.THUMBNAIL == 'easy-thumbnails': | ||
_formfield_overrides = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This seems to override the _formfield_overrides
when a RichtextWidget is set.
It's also not clear to me why a separate _formield_overrides
is used instead of directly setting/updating formfield_overrides
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That is correct. Ultimately this is largely a personal stylistic choice so that we only have one spot where we set the attribute value, but we could achieve the same effect with if/elif/else statements and set the value directly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer setting them directly as I feel non-functional code does not contribute to clarity.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Updated with requested changes.
source_image = parser.compile_filter(tag_args[1]) | ||
|
||
# Return the thumbnail | ||
return ThumbnailNode(source_image, tag_args[-1]) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I do think providing (and thus maintaining!) thumbnail code is really out of scope from django-newsletter!
My suggestion would be:
- For now, to default to
sorl-thumbnail
for backwards-compatibility but to yield aDeprecationError
if no thumbnail facility is explicitly configured. - In the next major version, failing hard if none is defined. We might make sure there's a no-op thumbnail facility by default.
I am open to your suggestions on this one though!
Super happy with this great contrib!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that plan and I think it makes perfect sense. I have no doubts there are countless pitfalls with proper thumbnail generation we aren't accounting for here and it could create some concerning feature creep.
I'll look at making the suggested updates and remove this block (and updating the other impacted code sections).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Set this up to raise a DeprecationWarning
if no NEWSLETTER_THUMBNAIL
is declared and then default to sorl-thumbnail
. I have set the warning to say this will become a mandatory declaration for version 0.11.0 (I assume the warning itself will kick in for version 0.10.0). I updated some details in the installation and setting docs to cover this change as well.
Thanks for taking the time to review and provide the feedback @dokterbob - really appreciate it! I will try and find some time to make the changes around the thumbnailer functionality in the near future and get another version out. |
Adding depreciation warning for users who have not declared NEWSLETTER_THUMBNAIL
Correcting typos in comments
Adding tests for new functionality
Add tests for new functionality and to better test dynamic imports
Okay, had some time and pulled out the thumbnail functionality. I left comments to some of your other questions and can make any additional changes as needed quite quickly. Thanks! |
.travis.yml
Outdated
@@ -39,8 +39,6 @@ install: | |||
# Latest PIP uses wheel by default | |||
- pip install --upgrade pip | |||
- pip install $DJANGO | |||
- pip install -r requirements.txt | |||
- pip install -r requirements_test.txt |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer you take this file straight from master, where CI seems working just fine. :)
newsletter/admin.py
Outdated
models.TextField: {'widget': newsletter_settings.RICHTEXT_WIDGET}, | ||
} | ||
|
||
# https://easy-thumbnails.readthedocs.io/en/latest/usage/#forms | ||
if newsletter_settings.THUMBNAIL == 'easy-thumbnails': | ||
_formfield_overrides = { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would prefer setting them directly as I feel non-functional code does not contribute to clarity.
…ependency. (#304) * Removed sorl-thumbnail as a dependency. * Added a new setting (NEWSLETTER_THUMBNAIL) which allows users to specify a third party thumbnail application. * Integrated support for two thumbnail applications: sorl-thumbnail and easy-thumbnails * Removing some Python 2.7 conditional imports
…ependency. (#304) * Removed sorl-thumbnail as a dependency. * Added a new setting (NEWSLETTER_THUMBNAIL) which allows users to specify a third party thumbnail application. * Integrated support for two thumbnail applications: sorl-thumbnail and easy-thumbnails * Removing conditional Python 2.7 and pytz (already required by Django) imports in tetst
Merged, at last! :D Thanks, @studybuffalo! Ref: 2ce29ba |
@dokterbob the migration that was merged with 2ce29ba is called What do you think? Is it necessary to rename this one to |
Oh, that's a silly human bug right there. We might quickly renumber them, before anyone uses it (or else they'll have to manually rewind and re-apply). What do you think? |
This is a pull request to address the dependency issues caused by conflicting versions of django-newsletter, sorl-thumbnail, and Django. It removes the hard dependency on sorl-thumbnail and provides alternative fallbacks if sorl-thumbnail is not used. With this work it was easy enough to extend functionality to include other thumbnail applications. Thus, I have also included easy-thumbnails support to give users another option and serve as a template for any future support for other thumbnail applications.
Major Changes
sorl-thumbnail
as a dependency.NEWSLETTER_THUMBNAIL
) that allows user to specify a third party thumbnail application for use with django-newsletter.sorl-thumbnail
andeasy-thumbnails
image
field in theArticle
model to support swapping between thumbnail applications by creating a model field that will inherit from the appropriate application. This avoids issues where Django will try to make a new migration anytime the user swaps the app. By default, this field will fallback to the DjangoImageField
if there is no thumbnail app specified.SubmissionArchiveDetailView
to select an appropriate template to thumbnail anyArticle
images. Users can override thenewsletter/message/thumbnail/django_newletter.html
ornewsletter/message/message.html
template if they need to implement a different template.ArticleInline
class to make use of the appropriate thumbnail application widget as specified by the user (or the normal Django widet if not specified).travis.yml
that stops installing directly fromrequirements.txt
. This forces the tests to install as though it were a proper PyPI package and catch any odd requirement issues.Other Comments
upgrading.rst
file has not been updated yet, as I am not sure which version this would fall under and if there are major changes to still take place.Questions before review
Relevant Issues: #302, #303