Add to generate Plone image scales on save (opt-in)

[datakurre]

when environment variable PLONE_SCALE_GENERATE_ON_SAVE=1 is set

[mister-roboto]

@datakurre thanks for creating this Pull Request and help improve Plone!

To ensure that these changes do not break other parts of Plone, the Plone test suite matrix needs to pass.

Whenever you feel that the pull request is ready to be tested, either start all jenkins jobs pull requests by yourself, or simply add a comment in this pull request stating:

@jenkins-plone-org please run jobs

With this simple comment all the jobs will be started automatically.

Happy hacking!

[datakurre]

@jenkins-plone-org please run jobs

[datakurre]

@jenkins-plone-org please run jobs

[jensens]

@jenkins-plone-org please run jobs

[tisto]

@jenkins-plone-org please run jobs

[tisto]

@plone/framework-team we would like to get feedback on this PR if possible. It is non-intrusive, non-breaking and the feature is purely optional. IMHO there is no risk in merging it and no need for an FWT vote IMHO. Though, a quick feedback/discussion would be nice.

[datakurre]

Motivation for this in brief:

• for the current web, more and bigger scales are needed
• creating scales on request can make terrible user experience on image heavy landing pages
• especially true for Volto, because Plone REST API would the create all scales on single request
• replacing Plone scales with other solution would require reinventing cache invalidation for scales, so optimising plone scales might still be the easiest solution

(Also more fixes for scaling is possible. I recall that scale ids are now random, not deterministic, which may lead to broken images on strongly cached html. I have local patch for that, but no proper pull request. And also scaling itself could be made faster by making it async and parallel [there’s an experimental branch on plone.namedfile].)

[frapell]

+1 from me on this.
I don't like the idea of not voting it in the FWT however under current times, I understand the reasoning and agree that it is a safe change, so I am fine if there is no voting.

[tisto]

@frapell if this is something that the FWT should vote on, we should vote (or wait for the vote). I don't mind either way. :)

[ale-rt]

As a reminder the @plone/framework-team has received an invitation for the next meeting on Tue 29 Jun 2021 15:00 – 16:00 (CEST). Let's make it happen that day

[ale-rt]

BTW this functionality can easily be incorporated in an addon.

[ale-rt]

This looks good to me, I just added some remarks to avoid having too many functions in the datamanager module.

[ale-rt]

On the last meeting, the @plone/framework-team talked about this PR.
We decided there is no need for a PLIP.

[datakurre]

Alessandro's review has good ideas for making this pull better before merge.

[datakurre]

@jenkins-plone-org please run jobs

[datakurre]

@jenkins-plone-org please run jobs

[datakurre]

@jenkins-plone-org please run jobs

[datakurre]

I wonder what this

Failed doctest test for widget.rst
  File "/home/jenkins/workspace/pull-request-6.0-3.7@3/src/plone.formwidget.namedfile/plone/formwidget/namedfile/widget.rst", line 0

----------------------------------------------------------------------
File "/home/jenkins/workspace/pull-request-6.0-3.7@3/src/plone.formwidget.namedfile/plone/formwidget/namedfile/widget.rst", line 755, in widget.rst
Failed example:
    PIL.Image.open(six.BytesIO(content.image_field))
Expected:
    Traceback (most recent call last):
    ...
    OSError: cannot identify image file...
Got:
    Traceback (most recent call last):
      File "/srv/python3.7/lib/python3.7/doctest.py", line 1337, in __run
        compileflags, 1), test.globs)
      File "<doctest widget.rst[264]>", line 1, in <module>
        PIL.Image.open(six.BytesIO(content.image_field))
      File "/home/jenkins/.buildout/eggs/cp37m/Pillow-8.2.0-py3.7-linux-x86_64.egg/PIL/Image.py", line 2968, in open
        "cannot identify image file %r" % (filename if filename else fp)
    PIL.UnidentifiedImageError: cannot identify image file <_io.BytesIO object at 0x7f83122711d0>

is. I think I saw that already before the latest changes.

[jensens]

PIL 8+ now raises more specific errors. This is fixed on master, rebase this branch.

[datakurre]

@jenkins-plone-org please run jobs

[datakurre]

@jenkins-plone-org please run jobs

[datakurre]

I noticed that master targets >= 3.0.0 with Plone 4 no longer being supported, so I removed the compatibility code from this pull.