Feature: Store processed images in persistent directory

[dahaupt]

Generated images should never be stored in the directory fileadmin/_processed_/, as they are removed for example when cleaning temporary files within the install tool. In this case the URL of the image in the already sent newsletters will be broken.

We currently avoid this by uploading the images in the exact resolution so that no new generation happens. However, this is not very convenient for editors. It would be useful if the maximum image size could be set based on the layout column and generated images were saved to a fixed folder.

Looking forward to any feedback or already existing approaches! Feel free to ping me in Slack (TYPO3 Workspace) for further discussion.

[einpraegsam]

I understand your problem in general. This is not that easy to handle because if your are processing images from fileadmin, they are automatically stored under fileadmin/processed/ of course. I'm wondering if this is a real problem. If you are generating a newsletter and the queue is filled with some tasks. Let's say this would need 2h to send all the mails - is it a real problem if this 2 hours are blocked for removing temporary images?

[dahaupt]

@einpraegsam Thanks for your fast reply! I am not sure if I get you right on this. Generally, we do not remove temporary images as part of a scheduled task. It would be done manually (or more by accident). In that case, however, the links to the images in the already sent newsletter mails would be broken as those files were removed.

So if the newsletter will be sent with processed images, those have to be safe from a cleanup task.

Basically, my request could be divided into two parts:

1. Configuration of maximum image sizes based on template and columns (probably outside the extension scope, but best-practice config would be great).
2. Hooking into the image processing and store the images in always persistent directory (e.g. fileadmin/luxletter/images/{newsletterId}/ or another configurable directory).

Additional notice:
From my experience, it is important to have the exact desired image size for displaying images in the newsletter (using the width attribute does not work in some email clients).

[einpraegsam]

Okay, but let's go a step back. You are writing of a problem when newsletters are already sent to the receivers. And for any reason the receiver opens the newsletter mail 3 days later. Now - if the temporary images were removed - no images can be shown? What about image embedding? You can enable this feature in general extension configuration.

[dahaupt]

And for any reason the receiver opens the newsletter mail 3 days later. Now - if the temporary images were removed - no images can be shown?

This is exactly the case I am referring to.

What about image embedding? You can enable this feature in general extension configuration.

I have already tested it, and it would be a working solution. However, I don't know the possible side effects and risks of embedded images (e.g. larger email size and client support). I would still use the feature assuming we would use any processed images (should/could be recommended then in the docs?).

But first, we have to adjust our configuration so that the image sizes (especially the width) are set by column and used for processing. How can we achieve that? As this seems to be specifically important for email newsletters, I'd love to see a configuration (example) provided by the extension.

[einpraegsam]

Okay, we should add a comment to FAQ: Upside and downside of image embedding

At the moment I don't want to implement a different way, how TYPO3 is processing scaled images.

For you: You can change the image processing as you want. See fluidStyledMailContent.