Search

That's quite a good idea. I reckon it should be an option to choose from.

it should be easy enough, given the way klaftertief leverages his implementation of jit image manipulation. i might look into it today, if i can beat this mean hangover ;)

Would it be possible to save both the original and the cropped image, and later retrieve it somehow from the same image entry, listing both image sin the nodes?

The Image Cropper doesn't save or touch the image files itself. So one would have to write an extension that subscribes to the EntryPostCreate/Edit delegates to save the different versions of an image. The extension should be independent from the Image Cropper, because it should not be limited to cropped images only.

@ klaftertief
Are you saying the imagecropper only associates cropping size/position to be used by JIT? If so then I don't need the cropped file being saved, the only thing I want to do is be able to show the original file and the cropped file, but this could all be based on the original file and JIT?

Yes, the imagecropper only saves the coordinates. So you only have to include the upload field and the imagecropper field in your datasource. I assumed you wanted to pre-modify the images to circumvent JIT for performance reasons.

Please look at this post:

http://getsymphony.com/discuss/thread/50421/16/#position-305

Is it Nils' fault, or Yours? :)

The implementations of the prepareTableValue function usually don't have a third parameter for the entry_id, but it gets call in content.publish.php with this parameter. This is what I'm using in the prepareTableValue function in the imagecropper. So it's the imagecroppers fault. As a temporary solution you can just comment out the prepareTableValue function in the imagecropper until I release a fix.

You can change line 482 and 483 in field.imagecropper.phpto

function prepareTableValue($data, XMLElement $link=NULL, $entry_id = NULL){
    if (isset($entry_id) && $data['cropped'] == 'yes') {

But it might not be the proper solution, because of the reasons mentioned above. Will check it out with the core team.

It kind of works with that fix. For now at least.

Thanks for help.

What does kind of mean?

Field: Image Cropper updated to version 1.0.2 on 26th of June 2011

  • Fix for issue when an imagecropper field is used in a subsection
  • Fix for minimum dimension rounding issue

Any plans to integrate Subsection Manager and Imagecropper such that you can crop an image linked via subsection? This would be great for an unspecified number of crops on a single image upload. I might attempt to hack it together myself in the mean time but just checking if something like this is already underway?

I'm using a modified Uploaded Files Select Box field for this kind of stuff. It's based on stage, which also builds the interface of the SSM. But it's dependends too much on the project where it's used to be publicly availabe. Yet. Because the SSM is so configurable a general integration is not on my todo-list.

To hack something together you would have to add the SSM to the supprted fields in the imagecropper, to be able to set the relationship. Then you would have to define a SSM caption setting to add the src attribute of the image. Finally the JS for the publish page needs to be adapted to get the src attribute for further processing. And the SSM should probably set to single mode.

Hope I could help a bit.

I'm getting 500 responses for URLs like image/4/3707/2469/177/250/3707/2469/. Seems the server doesn't like those high resolutions. Anyone else experiencing this?

This sounds like a general JIT memory issue. Try increasing the memory limit. Or decreasing the image size ;-)

It is important to understand that the major part of memory consumption is not the original image size in bytes but the decompressed size. (Images must be decompressed in order to perform calculations on them.)

JCrop seems to be working fine but the modified Jit is not working for me. I'm getting 500 responses for all urls (even normal jit urls - with no crop values).

The images are not large. I'm using Symphony 2.2.5 and the latest extensions running on MAMP Pro.

Woking now! Downloaded the branch jCrop from https://github.com/klaftertief/jitimagemanipulation instead of the Master!

Downloaded the branch jCrop from https://github.com/klaftertief/jitimagemanipulation instead of the Master!

Yep, I have to send a pull request to merge the jCrop mode into master...

Is it still possible to use background colour with this imagecropper field and Modded Jit? i.e

/image/4/crop_width/crop_height/crop_x/crop_y/resize_width/resize_height/fff/path/to/image.jpg

Image doesn't render if I use code similar to the above?

Create an account or sign in to comment.

Symphony • Open Source XSLT CMS

Server Requirements

  • PHP 5.3-5.6 or 7.0-7.3
  • PHP's LibXML module, with the XSLT extension enabled (--with-xsl)
  • MySQL 5.5 or above
  • An Apache or Litespeed webserver
  • Apache's mod_rewrite module or equivalent

Compatible Hosts

Sign in

Login details