Release: Thumbnails

[apeisa]

Haven't thought about that use case at all, to be honest. I think that best way to support that would be offering "real" image cropping tool, that creates copies of original image, not just reference.

[porl]

The main reason I asked was due to the fact that adding a resized image with a link to the fullsize image just acts as a hardlink to it. i guess i could override this with jquery for javascript enabled users to load the image in a lightbox type thing instead.

[Michael Murphy]

Thanks apeisa, I'm currently again testing with repeaters and there seems an issue with cropimages (not sure if images suffer the same) when I add a new repeater element on page with an cropimage field and upload an image, after saving the page the added element dissapears. Though after adding an element again there's still the image uploaded before (already reported issue on repeater thread, but think not solved yet). But after saving the page again then, it stays there and when clicking the "thumbnail" link a new window opens with this error:

Fatal error: Call to a member function get() on a non-object in /Applications/XAMPP/xamppfiles/htdocs/pw-dev/site/modules/Thumbnails/ProcessCropImage/ProcessCropImage.module on line 50

@soma did you resolve this issue? I am getting the same error when trying to open up the thumbnail cropper on all my CropImage fields (I have about 6). Not sure when this happened - I am using the field in some repeater elements - however the error is affecting all CropImage fields even those not in a repeater element.

The CropImage field is still working and creating all the thumbnails, it's just the crop edit window that is showing this error.

[Soma]

@soma did you resolve this issue? I am getting the same error when trying to open up the thumbnail cropper on all my CropImage fields (I have about 6). Not sure when this happened - I am using the field in some repeater elements - however the error is affecting all CropImage fields even those not in a repeater element.

The CropImage field is still working and creating all the thumbnails, it's just the crop edit window that is showing this error.

Nope sorry.

[interrobang]

@apeisa

A client complained about not seeing the whole image if it is larger then his screen. I was able to fix this simply by adding 2 lines (boxWidth and boxHeight) in ProcessCropImage2.js. Maybe you can add something like this to your official release too?

Btw, this module so really great, and my customers are loving it! Thank you so much for releasing it!

$(function(){
$crop = $('#jcrop_target');
if ($crop.length > 0) {
 var w = $('#jcrop_target').data('width');
 var h = $('#jcrop_target').data('height');
 $crop.Jcrop({
  onChange: showCoords,
  onSelect: showCoords,
  aspectRatio: w/h,
  boxWidth: screen.width - 100,
  boxHeight: screen.height - 100
 });
}
$('#show_preview').click(function(){
 $('#preview-container').toggleClass('hide');
})
});

[teppo]

I had the same repeater problem that Soma reported some time ago. Following changes to ProcessCropImage.module got it working:

			   $this->setFuel('processHeadline', 'Crop images');

+			   $field = $this->input->get->field;
+			   if (preg_match("/_repeater[0-9]+$/", $field)) {
+				   $pages_id = (int) end(explode("_repeater", $field));
+				   $field = str_replace("_repeater$pages_id", "", $field);
+			   } else {
			   $pages_id = (int) $this->input->get->pages_id;
+			   }
		   $filename = $this->input->get->filename;
-			   $field = $this->input->get->field;
		   $height = $this->input->get->height;
		   $width = $this->input->get->width;
		   $prefix = $this->input->get->prefix;

This is a bit of a hack and I haven't even tested it properly, so I'm definitely not saying that anyone should use the same method -- but it worked for me

[apeisa]

Thanks Guys.

Interrobang: tested and worked nicely - thanks for the tip, I just committed it. Great improvement.

Teppo: I think there should be cleaner way to see if field is repeater. Probably by getting the actual field an checking it's fieldtype. But this is great news to know the solution for this problem. Will look into this soon (before holidays I hope).

[apeisa]

Btw, this module so really great, and my customers are loving it! Thank you so much for releasing it!

Thanks to stillmovingdesign (http://stillmovingdesign.com.au/) for sponsoring it.

[apeisa]

Added the Teppo's fix for repeaters!

[97s]

So I have a simple question. I am doing something very wrong I guess, I have two issues.

Issue 1. When I go to hover over the thumbnail in the images field, it breaks. Not really sure what is going on here, but I can live with this issue. (found solution to this one.)

Issue 2. I can't figure out how to pull the thumbnails, if they exist into my template. I am currently using this:

<ul class='gallery'>
<?php
foreach($page->images as $image) {
$thumb = $image->size(500, 400);
echo "<li class='gallery-item'>";
echo "<a href='{$image->url}' class='albumImageLinks fancybox-button' rel='fancybox-button'>";
echo "<img class='gallery-image' src='{$thumb->url}' alt='{$thumb->description}' /></a>";
echo "</li>";
}

?>
</ul>

However, I want to pull a thumbnail if it exist for certain images which I need to crop using your module. I have tried everything in the directions, but I keep getting errors involving eq.

Sorry I am not the best at php.

------------------------------------------------

Solved my problem: for people in the future here is the code that worked for me:

<ul class='gallery'>
<?php
foreach($page->port_images as $image) {
  $thumb = $image->getThumb('thumbnail');
  echo "<li class='gallery-item'>";
  echo "<a href='{$image->url}' class='albumImageLinks fancybox-button' rel='fancybox-button'>";
  echo "<img class='gallery-image' src='{$thumb}' /></a>";
  echo "</li>"; 
}

?>
</ul>

Also you need to create a thumbnail settings that matches what you were going to use for the size parameters. For me I was using 500/400, if you describe these settings, they are defaulted, then you can crop to the size you need for specific pictures, the rest are center cropped, which is exactly what I needed! Thanks for this fantastic solution for cropping images!

[Marty Walker]

The problem you might have (I think) is if you change the fieldtype from Image to cropImage, it automatically creates a default thumbnail so you can't test for the absence of one and use your original Image fieldtype-cropped image. I might be totally wrong here though.

If you were using a one-page-per-image setup it might be easier because you can just serve an alternative cropped image.

[example written in the browser so not sure it works exactly]

<?php
$featured = $pages->get("/page/")->children;
foreach($featured as $feature) {
$thumbnail = $feature->thumbfield; /*check for the thumbnail field */
 if(!$thumbnail) {
 $thumbnail = $feature->imagefield->size(400,500); /* if no thumbnail field just use the regular image field */
 echo "<img src='{$thumbnail->url}' alt='{$feature->title}'/>";
} else {
 echo "<img src='{$thumbnail->getThumb('thumbs')}' alt='{$feature->title}'/>";
}

Regards

Marty

[apeisa]

Just merged pull request from Ryan, which includes few nice improvements to this module:

1. Support for securefiles (coming in 2.3)

2. Works on regular image files

3. Some minor code tweaks (sanitizing & indentation)

Ryan: about "works on regular image field also": how does it work? Thumbnail settings are set per field basis, and the setting field is visible only when fieldtype is cropImages - so where does it get thumbnail sizes for regular images?

I tested the commit before merging and it didn't break anything on my test installation - so it should be safe to just pull in the latest changes.

Thanks for the update Ryan!

[ryan]

4. One other thing I added: If you delete an image, it won't leave the crops behind (they get deleted too). Previously the crop files would stick around even after the original image was gone.

Ryan: about "works on regular image field also": how does it work? Thumbnail settings are set per field basis, and the setting field is visible only when fieldtype is cropImages - so where does it get thumbnail sizes for regular images?

The field config is defined in InputfieldCropImage.module rather than FieldtypeCropImage.module, so that's why it works. It's more your doing than mine, as I only had to tweak a couple things to make it work. It was an accidental find too. Meaning, I wasn't intending to add this specifically, but noticed it worked through my own error of forgetting to change the fieldtype. It's possible I'm missing something, but it all seemed to work fine here. Of course, the FieldtypeCropImage is still a necessary component. But it's acting like an autoload module, adding hooks to Pageimage and Pageimages.

[apeisa]

Ah, actually the per field settings were another community contribution. I think it wouldn't be too hard to get rid of the FieldtypeCropImage alltogether, need to take a good look at it some point.

[aleksblendwerk]

I just added this module to a standard 2.2.9 installation, had two existing posts with images already uploaded using the core 'Image' field type and changed the 'images' field's type and input field type to 'CropImage'.

Now I am getting a 'There is no thumb called thumbnail' message (with the rest of the page being blank, no input forms displayed) whenever I open an existing post with previously uploaded images. When I create a new post, I get the same message within the image upload form after uploading an image.

Any idea what I am doing wrong?

[apeisa]

From mobile: check field settings and resave the field. Empty modules cache.

[aleksblendwerk]

From mobile: check field settings and resave the field. Empty modules cache.

Emptying the cache and resaving did the job. I also temporarily added a second thumbnail configuration but removed it again, so I am not sure what the actual problem was. Thanks for the lightning fast support!

By the way: the whole UI is really state of the art, props!

[Soma]

It has problems if you change a image field to cropimage field. At least it was for me.

[bfncs]

Thanks a lot for this great module, this really makes image handling in Processwire a breeze.

That said, I'm looking for a quite specific feature that seems to be hard to accomplish with the current module. I'd like to recrop a given image with the same visible section as a given image version. Imagine I have an image version for crop image set up to be 150x100. Then I need a version of that image in 100x100, but cropping from the section that was selected for the 150x100 version. The new image should be generated from the originally uploaded one to not run into more issues with quality, for sure.

Does anyone see a way how this might be possible already?

And can this be integrated in the module? I'm imagining something like

$page->myImage->getThumb('sizename', 100, 100);

With kind regards, Marc

[apeisa]

That is really special edge case, I don't think I'll take this module into that direction, sorry Marc. But of course you could use this module as a starting point for your need for sure. Difficult to say how to achieve that goal though...

[bfncs]

Thanks for your quick answer, Anttii!

I can really understand that this doesn't fit in there too well. Still I'm wondering how to do it, too.

One option would be to define addional sizes that inherit proportions and section from another size in the field settings already:

thumbnail, 150, 100
thumbnailvariant, 100, 100, thumbnail

'thumnailvariant' would then not be shown when editing the field and might be generated right after 'thumbnail' is generated. This wouldn't enable to get arbitrary sized images, but should be relatively easy to accomplish and would definitely fit my needs at the moment.

To enable this, it would be necessary to store the data from jCrop (x and y coordinates, width and height) in it's own table in the DB to do custom crops based on that data later. This variant sounds like a lot of work but also would be a great basis for a lot of other features that might come later (i.e. being able to change the proportions of certain image sizes without losing all custom crops already done by batch processing existing images).

I'll definitely wrap my head around this, might take some time though.

[ryan]

Does anyone see a way how this might be possible already?

I think that you can do this all with CSS. Once you've got a crop, you can automatically CSS position it within a markup container (that has overflow hidden) to achieve variations like those you mentioned. That is, so long as the crop is something smaller than the original. You could go about it either using an <img> in a <div>, or just a <div> with a background image. If you need to just scale, or scale and crop, you'd probably want to use an actual <img> tag that specifies either the target width OR height (not both) with the other dimension overflow:hidden by the container. If you are supporting high DPI/retina displays, you are probably already doing this to some extent, in terms of the scaling aspect. 

[bfncs]

Hi Ryan, thanks for your answer. I think you're pretty right for a lot of use cases, but this doesn't serve my use case here.

I think I didn't make it clear enough that I don't only want to crop but zoomcrop, cropping of the larger dimension so that after zooming the smaller dimension fits. Also I want to use these different versions of the image on different pages (overviews, recommendations to other pages, etc).

I still might scale browserside with an <img> tag resized with CSS, but this isn't a good practice, the resizing of older browser is quite bad and it will limit me to an aspect ratio.

For the project I'm working on now, I'm just going to add another image variant in the CropImage field settings. This is a little less comfort, but since this won't be used too much either way, I can't afford to spent the time to rewrite the CropImage module to serve my needs. I'll definitely come back to this, because I think that I'd still want to see this in the module.

Thanks for all your help so far,

Marc

[ryan]

I still might scale browserside with an <img> tag resized with CSS, but this isn't a good practice, the resizing of older browser is quite bad and it will limit me to an aspect ratio.

This was a bad practice years ago. Correct me if I'm wrong, but this is not a bad good practice now, at least if you want to support high DPI screens? I mean if you go inspect the ProcessWire logo in the upper left hand corner and open it in a new window, you'll see the actual image is much larger than it appears on the site. That's the only reason it looks sharp on a retina screen. Yes, this might make it look bad on IE6, but well… if you are using IE6, life is already a bummer.

The purpose of specifying one dimension with the <img> tag and using an overflow:hidden for the other is to prevent any stretching of the image (maintain aspect ratio).

I've not personally used this technique, so not speaking from experience. But it seems so simple that I'm inclined to try it. 

I think I didn't make it clear enough that I don't only want to crop but zoomcrop, cropping of the larger dimension so that after zooming the smaller dimension fits

Unless you are talking about upscaling an image (I'm guessing not) then it just means you've got to start with a bigger crop, in terms of physical dimensions.

[bfncs]

Ryan, you're pretty right about everything you said there, but I just didn't make my use case clear:

I don't want to support retina screens, but I want completely different version of an image while saving the same clipping. What I want is for example let the user crop an image to 400x300 with the CropImage-Inputfield and use this image somewhere (i.e. as a preview in article overviews) as it is.

At another place I want the same image sized to 200x100. Everything's different about this, the size and the aspect ratio. I don't want my user to crop to this size on his own (because that might get a lot of different versions of an image for a large site) and I just assume, that what is in the 400x300 version is the most important part of the image and will work in the smaller dimension, too. So I want to zoomcrop my 200x100 version from the center of the 400x300 version, but not working with that image again but with the original image to get the best quality.

I hope this is more understandable now