Thanks for the feedback.
Good point, it is possible to do both. However that’s also more work and still has the problem of being completely separated from the view and affecting all image uploads delaying it in places where it’s not wanted, e.g. uploading images in the inspector.
Additionally we currently have at least four different thumbnail sizes used for images: the image view, the list view (mini and zoom – only fetched from server when needed) and the inspector. Generating all of those doesn’t make much sense, since they’re only potentially needed, thus the generation as needed solution is preferable.
Unless we decide to create some view independent sizes to use instead, like two or three generic sizes and use them in the views instead. That would mean less optimal image file sizes, but streamline it. Could even be configurable in settings, like:
TYPO3:
Media:
autoGeneratedThumbnails:
small:
width: 50
height: 50
large:
width: 200
height: 200
And use that configuration in the views width="{settings.autoGeneratedThumbnails.small.width}"
Another approach is to create a command controller that looks for ungenerated thumbnails and generates them. This wouldn’t have the regeneration problem and would be opt-in. The challenge would be creating those ungenerated thumbnails, although this approach has the exact same problems except for not delaying uploads.
Btw. it’s also possible to put all this behind a feature flag, so it’s possible to opt-in or out depending on the default.
So actually to summarize, a good solution could four steps:
- Asynchronous image URL
- Create generic thumbnail sizes
- Create command controller for generating ungenerated thumbnails
- Put everything behind feature flags
WDYT?