Hey NEOS Team,
I come to you in a great time of need … with a feature request and maybe a solution
Focal points for images are a really important feature to have especially in responsive websites with multiple aspect ratios for different devices. This feature is currently
missing from NEOS but - in the shortest way possible: We need this. And: We are willing to implement this into the NEOS core.
For this there’s this small introduction and some questions that need to be clarified first.
If you render images that are not uploaded to NEOS within a NEOS project there is currently no way to influence where the image will be cropped.
This can lead to “sub-optimally” cropped images especially with responsive images with multiple aspect ratios. You can work around this when the images
are sourced from NEOS by adding an additional property to your elements. One per aspect ratio. But this is not only inconvenient for the backend user
it’s also just not feasible if you have more than 2-3 aspect ratios.
As I see it it’s also currently not possible for external images (e.g. images you render using deep links let’s say from an HTTP API) as there is currently no way to get the focal
point information to the layer that crops the images.
Instead of a “focal area” as it exists in TYPO3 we propose a simple “focal point”. This will cover the OVERWHELMING amount of use cases while cutting down
some complexity that is (in our experience) not needed for the web.
The focal point can be set in the media collection for each asset. The GUI therefore just needs a relatively simple “Click to set” event to generate X/Y coordinates,
a “cross-hair” on the image to visualize it and an “remove” button. If cropping is used in an inspector the focal point for that component is “discarded” since the crop
should take precedence. Of course a focal point in the inspector similar to cropping would be possible but this would increase the complexity tremendously and is probably
The backend already generates a box for creating the variants. The assets need to be extended by the X/Y coordinates and the box needs to take those in account along with all the
other “don’t exceed the image dimensions” calculations that are being done. We did something similar for our very own imx.CMS:
As the PHPDoc for the above cropping strategy states it just enforces the aspect ratio while preserving as much of the original image and keeping the focal point visible. Or: The focal point
mostly decides the corner from where the cropping starts. This solves pretty much every use case.
We tried several other strategies but beside this one only one other made it into the final code and we never used it in production.
After all, not that complicated and not too far off of what NEOS is doing right now.
We have several projects with several customers that have asked specifically for this feature (it was available in their previous CMS after all). This means we would need this “as soon
as possible” (what a surprise, eh? ) The github issue on this has seen no further communication since 11/2018 https://github.com/neos/neos-development-collection/issues/2296
I remember reading about a “rework” of the asset manager. Is this still the case? If so, is something like focal points already planned?
Is my initial assumption correct that there’s no way to get the info to the cropping logic? As I see it the \Neos\Media\Domain\Model\ImageInterface is the breaking point since this is all
that’s available when cropping images.
Is this even a wanted feature? I would assume so since it’s really important for users to have and the issue hasn’t been closed (yet)
What would be the next steps? I assume there needs to be some kind of preparation/spec to be done so it’s probably not a good idea for us to just fork the repo and get going?
Feel free to reach out for questions. If it speeds things up we can also switch to German. You can also @ me on The NEOS Slack (@BastianSchwarz)
As I said: Our customers are already asking for this so it would be awesome if you could give me a first quick response rather soon so we at least know if/how we can proceed with this feature.