wagtail
wagtail copied to clipboard
wagtail
Allow editors to rotate images within the Wagtail UI
Allow editors to rotate images within the Wagtail UI. It can be a pain to have to do it manually outside of the CMS.
To say we get this feedback quite a lot from clients.
I think it's one of those features that editors expect to see, and get quite frustrated when it isn't there. It doesn't fit their mental model of what a CMS is, and there isn't an obvious explanation to give them of why it's not there.
The most obvious out of the box example of this working is at https://en.support.wordpress.com/images/image-editing/ but it's also there in Craft, in Drupal (with a module) and a number of other CMSs
I recognise it's not an easy thing for us to introduce, but does feel like something that would bring quite a lot of value to users.
In the spirit of "five whys" questioning... I have to wonder, what's the use case for this? (i.e. under what circumstance does a user upload a file with incorrect orientation that has to be fixed?)
If it's for photos taken in landscape vs portrait - since Wagtail 1.4 (/ Willow 0.3) we check the EXIF metadata on images and handle the rotation automatically. Is this perhaps a sign that this feature isn't working as intended? Or do we just keep encountering files where the EXIF data is missing or incorrect?
(Also, just to check - am I right in thinking that the request here is for rotating in multiples of 90˚? Or is there demand for supporting 'free' rotation too?)
Hi there, when working on a wagtail site recently I stumbled over this too.
In my case, I was migrating an existing site from Django CMS, and I wanted to use Wagtail's image tags in templates, instead of the previous hand-rolled image tag implementation.
I was able to work out how to import the photos and associate them with an existing model instance (I've shared the code in this gist, but they didn't all have correct EXIF data, so in some cases they ended up rotated 90 degrees the wrong way, and either myself or admin staff have to fix them manually when we see them.
So, the use case might be automated import of existing images for use in Wagtail, where you don't have reliable EXIF data, but want a quick way to 'fix' the image.
In my case at least, rotation in increments of 90 degrees would be plenty.
Implementing this:
I've had quick look through Willow, and my guess is that you'd need to support these two actions to have server side rotation through steps of 90 degrees.
http://docs.wand-py.org/en/0.4.3/guide/transform.html#rotation http://pillow.readthedocs.io/en/3.3.x/reference/Image.html?highlight=rotate#open-rotate-and-display-an-image-using-the-default-viewer
I'd also assume that you'd want any thumbnail images to reflect the newly rotated state too.
This sound about right?
There are a large number of reasons an editor could have an image that isn't correctly orientated. I regularly have to rotate images from workshops that I could quite easily want to use in a case-study or blog post.
Facebook, for example, allows you to rotate images because it doesn't presume photo orientation is always going to be correct and a lot of people may not know how to change it themselves/have software to do it and to be honest even if you do it's a pain to have to open some other software for such a simple task. In fact I would suggest most developed applications that deal with some form of uploading of images allow you to do this (Facebook, Flickr, Instagram, Tumblr) and I doubt their use case is simply about inaccurate EXIF data.
I think this is also a good example of where we could do with more user input to help make these types of decisions. Hypothesizing over use cases and user's priority for new feature development is neither user-centred or accurate.
@tmsndrs Sure. I'm not disputing the fact that there's a problem to be fixed here - just wanted to be sure that we weren't overlooking a better solution (getting orientation right to begin with) in favour of the more obvious and direct one.
👋 @mrchrisadams is going to work on this over at Wagtail Space. If anyone has some input on the approach UI-wise or on the backend, now is a good time. Ping @benenright for some input.
Just a note that an old PR for this feature has been closed https://github.com/wagtail/wagtail/pull/5139
May still be worth looking at though if someone does want to contribute to this issue in the future.
Additionally there is a plan to eventually get to the jQuery crop/focus UI on the images page and redo this with Stimulus and a modern library. No issue raised yet for that though.
Cropperjs v2 seems like it could be coming out this year and shows some promise.
https://github.com/fengyuanchen/cropperjs https://fengyuanchen.github.io/cropperjs/v2/
@kituuu we are looking a bit more holistically at the upload interface and what overlap there might be in the image focal point usage. This issue is specifically about extending the current focal point manager to be more of a mini-image editor (maybe cropping and rotation).
I think for now this will need some more research into libraries available and how we could support cropping/rotating AND the focal point chooser mechanism. Without jQuery.
This may also be a use case for a small scale standalone React component as this is unlikely to need any internal modifications from template driven HTML. We also may want to leverage a backend approach to modifying the image, this could mean we can leverage the Willow library instead https://github.com/wagtail/Willow?tab=readme-ov-file#available-operations - this is the approach taken in the previous PR.
For now, it's on the radar as a low priority research item, any research would be helpful but it's probably a bit too large for contributing without a clear direction.
However, if you are up for suggesting a way forward here and have an idea of how to do this in steps, please feel free to do some research and report back.
@lb- I have used some npm libraries in one of my projects. Lemme try to find something for this. But as you said it is a low priority right now. Ig, I will look into other important issues first.