Posted by animelion on August 31, 2011 at 6:50pm
6 followers
Jump to:
| Project: | Imagefield Crop |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | postponed (maintainer needs more info) |
Issue Summary
I uploaded the image "jcFg4.jpg" which is a 2560x1600 resolution, and I cropped it to 150x150. Upon viewing the node the 150x150 image is being displayed, however the file is still "jcFg4.jpg". I thought maybe the module was writing over the original, but instead the original was renamed to "jcFg4_0.jpg". I'm not sure if this is intended behavior, but I would expect the cropped image to be renamed to something like "jcFg4_cropped.jpg" with the original image upload remaining unchanged.
Comments
#1
Agreed, that would be the expected behaviour.
If starting to use this module "already in this state", and such a change comes "late", then we will have to tidy among the existing files and nodes, which might be "daunting". Upping to major, as this is close to a showstopper for those of us who are "on the fence", currently considering if/when to start using it.
As a minimum, it would be great to get a confirmation from the developers whether this will be changed or not. (IMHO it is important to correct this.)
#2
The module is only a widget, therefore it cannot change the name of your file in the field. The only way to make this work is by keeping the original file name in the cropped version.
Branch 7.x-2.x of the module is an experiment in making this module a full fledged field, so it might be possible there.
However, why do you see this as a major issue? I have never seen this behaviour as a problem, nonetheless a show stopper. Please elaborate.
#3
By "major", I mean that if someone starts using this module in this state, and then a later version of the module changes this behaviour (naming of files) to the exact opposite method, then there will be some cleanup to do in both the file system and existing nodes, to make the database consistent. Unless such fixing will be handled automatically by this module upon update, then this seems like a situation nobody wants to get into.
#4
If I understand this correctly, you are taking the current behaviour, assume it is flawed, assume it will be modified sometime in the future, and assume that the fix will not handle the change.
It's too much of a speculation for me, and I don't even see the big problem with the current behaviour to begin with.
Unless you can come up with a convincing reason to change that behaviour (and cope with the change in existing installations, I am not going to pursue that path.
#6
Alright, then we need more voices here to get a stronger indication about what is the expected behaviour. Lets keep it open for a while and see if some more people chimes in. In the current state of the discussion, this is not (yet) regarded as a flaw, unless more people support that notion. Adjusting categories etc. accordingly.
#7
Here is a screencast detailing the problem I'm running into. Below it is a brief description.
http://www.screencast-o-matic.com/watch/cXQjnN03u
A user uploads an image to be cropped, on the same node/add form they use KCFinder to add the same image to the body.
At this point only the origional image is in the folder, the crop image has yet to be generated. When the user selects the same image from kcfinder they are selecting the origional upload, but unknownst to them, once they save the form the cropped image will replace this one.
#8
At #7 this is good preview of the problem. I can add some other points to justify that mentioned in #7:
Use case (about every site i build):
1. crop image using imgafield_crop
2. display cropped image in node teaser
3. display cropped image in full node view + on the same image use colorbox to FULL untouched original image.
Now.. guess how do I do it?
I have to code node template to include untouched image.. how's that usable? I don't see why imagefield_crop does not create it's own preset and leave original image intact that other modules could use this image as well...
For everything I tried I was unable to get it work properly: cropped image (thumbnail) -> link to original intact image, because original image became cropped image...
P.S.: imagefield_focus does the job just right how it should be, why imagefield_crop can't work in a similar fashion?
#9
I'm running into the same issue, this is definitely a problem. It causes usability issues as outlined in #7 and functionality issues as outlined in #8 which is a use case I too use often.
Adding the cropped image as a new image instead of renaming the original version is definitely a better approach in my opinion, as other contributed modules such as colorbox and imagecache rely on the original image being untouched.
You could then provide a theme function to get to the cropped version of the image just like imagecache does.
#10
I agree with #7, 8 and 9 as well. It would be nice to have access to the original image when using imagefield crop as the widget of an image field. I just realized I could not use the original image after I added the field to a view display.