Posted by sethhill on November 1, 2011 at 2:04am
16 followers
Jump to:
| Project: | Imagefield Crop |
| Version: | 7.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | critical |
| Assigned: | Unassigned |
| Status: | needs work |
Issue Summary
We are experiencing the following behaviors after updating to Drupal 7.9:
- Uploaded image is not constrained to maximum cropping area defined in field
- Cropping tool does not appear after initial upload, but does after saving the node and editing
- However, the crop appears in its default appearance (i.e., the actual crop definition is never saved)
Comments
#1
I am experiencing this issue also. The image is not being constrained to to the cropping dimensions. I see that in the markup a width and height attribute is added to the image but it is not the size that I have defined for image crop.
#2
Wanted to confirm that I am also experiencing an issue with the cropped image maintaining the dimensions of the original file.
#3
Bumping to critical.
Will look into it when I have some time - any info or patches are gladly welcomed.
#4
This could be related to #1345744: cropped image has incorrect metadata width and height in imagefield that I saw with version 7.x-1.0 on core 7.9.
The symptoms are a bit different, as I can crop the image after upload and the image is cropped correctly, but height and width set in the img tag are of the original image. I could identify a dirty hack around for it in image_field_presave(), but need guidance for the proper solution.
#5
Oddly enough, I was having this same problem (or so it seemed), but this fixed it for me:
http://drupal.org/node/719714#comment-4570944
Coincidence? I'm running 7.x-2.x-dev on 7.9.
#6
same issue not... it doesnt crop the image .. shows full blown image even with crop selection.
#7
I am also experiencing this issue.
The patch in #5 did not work for me.
#8
I am also experiencing this issue. It's a huge problem for my client -- the site was designed around using this module. Please let me know if there's anything at all I can do to help debug.
#9
somanyfish, for now, you might want to try http://drupal.org/project/manual-crop
It's a really good module, with a lot of potential.
#10
I was able to get 2.x-dev working under 7.10 by fixing the linkit module, actually.
In linkit.js, they weren't checking to see if they could find the DOM element they wanted, and it was causing all of the attach behaviors to fail.
Does fixing this help anyone else? Or, if it doesn't fix it, are there any other modules doing the same? There will be errors in your JS console after you upload the file.
Issue here: #1394052: Linkit causing other modules' attach behaviors to fail [patch attached]
#11
The other issue is marked as fixed.
Can anyone else that is experiencing this bug check and see if they are using Linkit and if the newest 2.x-dev module fixes this issue for them?
#12
My client is not using LinkIt.
#13
Are you getting errors in the JavaScript console after an image is uploaded? It might be another module that is doing the same thing linkit was.
#14
I just checked and nope, I am not seeing any javascript errors in the console.
#15
I have this same issue and I am not using linkit either.
#16
No javascript errors in console here. Not using Linkit. Using Drupal 7.10. I confirm that the 2.x-dev version does not save the selected crop region. Tried various combinations of options and no luck with any. Also tried installing jquery_update module and no luck either. The 1.x-dev version works, just not the 2.x-dev.
#17
OK, I see the reason why 2.x does not work for me...it seems that 2.x has changed imagefield_crop to be a new field-type (Image Cropped) instead of just a widget type that we can apply to existing Image fields. This defeats the entire purpose of the module for me. I have existing content in fields and cannot change the field type. Guess I'll go back to the 1.x version.
It would be nice if this huge change was mentioned in the main module page or in a README file included in the module. Make people aware that they can't simply upgrade from the 1.x to the 2.x version of this module.
#18
Version 2.x is listed under "Development Releases" and is considered experimental for the time being. It is vastly different in design from the original idea, and that is why it has a different major version number.
#19
Yes, I understand that. But you still should have a readme file to explain the complete lack of compatibility and change of direction. Most modules put a 2.x section on their main module page to explain major changes like this.
#20
Ok, I've added a paragraph about version 2.x in the module's page. Thanks.