Release: Thumbnails

[apeisa]

Marty - do you get any errors?

[Marty Walker]

No errors that I can see. When I perform a crop it appears to do it but when I edit that page again and look at the crop it's gone back to the initial default crop.

[apeisa]

Does image resizing work in general? In API I mean.

[Marty Walker]

Yes all my templates are resizing images correctly.

[apeisa]

Can you check files folders that does the cropping tool create the files? And how about the url that module generates in templates?

[Marty Walker]

It definitely creates a crop image in the asset directory. But when I save the page that file gets overwritten again. I can let you in there if you want to have a look.

[Joss]

Hi Apeisa

I am still getting trouble with this module on the Dev version.

Exactly the same as before, except my work around is not working.

So, create a field, save it. Then save it again.

Check it with a new page and it works.

Change the thumbnail values and save it.

It now does not work.

Not only that, I cannot open a page to edit because it just throws an error saying it cant find the first thumbnail on the list and does not open the rest of the page for editing.

This seems really inconsistent. On another installation where I got it working it is still working, but on this brand new installation I cannot get it to work at all except with the default thumbnail value.

It seems to work as long as I have the first "thumbnail" in the list. If I take that out it fails.

But I am going in circles trying to clarify that

Joss

[apeisa]

Sorry Marty, I missed your last reply. You can send me access if want to, happy to take a look.

Joss: I will try to test this soon with latest dev. Do the problems occur when upgrading or with fresh install too?

Have others got this working on latest dev?

[Joss]

HI APeisa

I haven't done any upgrades, so this has only been with a new install. This particular time it is a very clean one as I have been writing a tutorial.

It does seem very inconsistent - On my current intall (2.2.17) it wont work unless I have "thumbnail" as the first thumbnail - the dimensions dont matter.

However, on another one which is 2.2.14 it is working fine without having "thumbnail" in the list at all - though I think that was the install that I managed the workaround I came up with before.

So, to be honest I am completely confused. I was trying to come up with a definitive set of circumstances where it did work or didn't work, but I have not managed that properly. Sorry.

I don't know if there is a browser caching issue going on that is confusing things.

It does seem to revolve round the default thumbnail in your script, which is what Soma pointed out before (I think it is on page 8 of this discussion). It is almost as if it is expecting to see something in particular and if it doesn't it chucks out an error or fails to upload the image at all - it cant find the thumbnail, therefore the image does not exist.

But I am guessing wildly!

[teppo]

@apeisa, I'm having same problem here that Joss reported. After creating the field it's settings don't initially get saved to fields table (which is probably how it's supposed to work -- I'm not exactly familiar with fields and can't say for sure), thus the need for that workaround Joss mentioned (saving it twice.) In my case it still seems to fix the problem, though, and I've been testing this in both 2.2.15 and 2.2.17.

Anyway, I was a bit curious why this workaround is even required. Your inputfield does offer default setting after all, and that shouldn't require any settings being found from the database. After browsing through some code (not nearly well enough, there's plenty of stuff there..) I think I may have found a problem:

There's a method called "_getInputFieldInstance", but it actually returns a field. "There's no thumb..." exception is thrown because default settings are always null, which in turn is caused by the fact that you were asking them from field, not inputfield.

Following change did seem to fix this situation, at least based on very limited testing:

--- a/FieldtypeCropImage.module
+++ b/FieldtypeCropImage.module
@@ -132,7 +132,7 @@ class FieldtypeCropImage extends FieldtypeImage {
                        // if the image's pagefiles property matches the one with the
                        // field we're looking at, we have a match. save in $field
                        if($image->pagefiles === $pagefiles) {
-                               $field = $imageField;
+                               $field = $imageField->getInputfield($page);
                                break;
                        }
                }

It's getting awfully late and my head is blurry, so I might have to take a better look at this later. Just posting it here in case that I can't remember anything about this tomorrow morning..

[teppo]

Just gave it another try and the fix I've mentioned above seems to be working properly. I'm including an in-depth explanation below, just in case you might want to see if there's a flaw in my thought process. I'm also using this module to learn about how fields, fieldtypes and inputfields actually work, so please bear with me..

When a field has already been saved (after initial creation, that is) all inputfield settings have been saved to fields table and thus field knows them too. This is why at this point you can ask "thumbSetting" from field and everything works smoothly.

As far as I can tell, inputfield doesn't strictly speaking even have settings of it's own -- it uses settings of the field it's attached to. Or perhaps it's better to say that they share the same settings at this point? Someone please correct me if I'm on the wrong tracks here.

Edit: now I'm really getting sidetracked, but if what I'm saying above is true, what would happen if fieldtype and inputfield had a setting with same name? Wouldn't that cause a conflict of some kind, ie. only one of them could save it's settings properly? What am I missing here?

A newly created field doesn't yet have any inputfield-specific settings stored, since at the time of creation it won't yet know which inputfield is going to be used and thus cannot guess what it's default settings might be. That's why you'd definitely want to fetch default value directly from inputfield, not the field. Inputfield is the one with default values included at code level after all.

So, create a field, save it. Then save it again.

Check it with a new page and it works.

Change the thumbnail values and save it.

It now does not work.

Not only that, I cannot open a page to edit because it just throws an error saying it cant find the first thumbnail on the list and does not open the rest of the page for editing.

This is something I've been unable to reproduce without relying on odd tricks. Essentially this sounds like your field had an image but still it's settings remained empty, which shouldn't really be possible.

One way this could happen is if you create an image field, upload image to it and then change field type to CropImage without saving it twice. This seems to leave field settings at database blank and that way cause an exception once you open page edit -- CropImage inputfield tries to render thumbnails for thumbnail list you see below images but doesn't have proper settings and fails with an exception.

When this exception happens at image upload phase, it just stops the upload process, but when it happens at this point it stops whole page from being rendered. Interesting stuff

Anyway, it would be nice to see what's inside your fields database table for this field (name = "your_field_name"). That might give us a clue why this is happening, or at least if it's caused by what I presume it might be.

Edited March 10, 2013 by teppo

[apeisa]

Thanks Teppo, makes sense to me. I have locally tested this and one earlier pull request (string translations support by boundaryfunctions). All seems to be working fine so I committed them to github.

Very happy if you guys can test that everything works as expected.

[Joss]

I have just done one quick test with the new FieldtypeCropImage.module file - and it went fine.

Create field - chose cropimage and add title - save.

Went to input - removed existing thumbnail setting, added two new ones and selected Display Thumbnail. Save

Added to template.

Opened existing page, added image. OK

Went back to field, added another thumbnail setting, Save

Reloaded page edit - OK

Went back to field, changed max images to 1 and set image upload sizes - save.

Reloaded page edit - OK

Closed pages and reopened - still OK.

So, with any luck that has solved the issue!

[Joss]

Are you going to update this so that it can update through Soma's Module Manager?

[apeisa]

Are you going to update this so that it can update through Soma's Module Manager?

What does it require? Updating the version number?

[Joss]

Hey, ask the evil genius - I haven't the foggiest!

[apeisa]

I updated the version number on both, modules directory and github. Does it work? (I myself pull modules directly from github, so not too familiar with modules manager).

[Joss]

Yep,, that did it!

[owzim]

Hi,

the module looks very promising. I am having trouble using it though.

In the backend everything looks fine. I can crop and all but in the templates ...

$repeater_items = $page->repeater_items;
foreach ($repeater_items as $repeater_item) {
	echo "<p>{$repeater_item->images->eq(0)->url}</p>";
	echo "<p>{$repeater_item->cropImages}</p>";
}

$repeater_item->cropImages gives me a NULL

What's wrong?

I am on PW version 2.2.9 and module version 1.0.1

[apeisa]

This is from the Readme:

FieldtypeCropImage adds getThumb-method to Pageimage. getThumb returns url to the thumbnail you have asked for, ie:
echo $page->cropImages->eq(0)->getThumb('thumbnail');

So in your case try this:

echo "<p>" . $repeater_item->images->eq(0)->getThumb('thumbnail') . "</p>";

[owzim]

This is from the Readme:

So in your case try this:

echo "<p>" . $repeater_item->images->eq(0)->getThumb('thumbnail') . "</p>";

Oh damn, sorry, I somehow assumed that cropImages is an extra object added by the module, but it is OF COURSE the name of the field.

Then again, I could swear I tried it before =)

Works now, thanks!

[Joss]

HI Apeisa

Just a note, if I am using, for instance, "thumbnail1" in my template, and I remove it from the list of thumbnails on the field, rather than just not working, it actually throws a server error,

The code in my template is:

    if($newspost->article_newsimage){
        $out .="<a href='{$newspost->article_newsimage->url}' class=''>";
        $out .="<img class='align_right' src='{$newspost->article_newsimage->getThumb(artthumbnail)}'>";
        $out .="</a>";
    }
 

 

While messing around with your update, I accidentally removed "arthumbnail" - so the image exists but the thumbnail doesn't. Is it worth adding something to your script so the result is not quite so dramatic?

 

[apeisa]

good idea joss, maybe the silent death might be better here.

[thingstodo]

Hi,

 

I'm new to Process Wire, I like the look of it and am checking it out.

 

I'm working through the "Simple News System" tutorial having done the "Basic Website Tutorial"

 

When I get to the part that uses the Thumbnails module I am having problems.

 

I've worked through the tutorial on two different servers and get the same problem 

 

When I try to upload an images I get an error messages like: There is no thumb called: listingimage

 

But the images are actually getting uploaded, resized and renamed.

 

However I did get it to work briefly on one occasion when I left the thumbnail setting at it's default value of:

 

thumbnail,100,100

 

Instead of the tutorial settings of:

 

thumbnail,360,280 
listingImage,280,170

 

However when I changed the settings it broke it again and setting it back to the defaults didn't repair it.

 

I'm using the latest version of ProcessWire and CropImage module (downloaded from GitHub last night) .

 

Any ideas?

 

Thanks 

Mike

[doolak]

@thingstodo:

Maybe you made the same mistake like I did:

 

Check if you are trying to get the thumb from Pageimages (one ore more images) instead of single image - this does not work.

Edit the image field and set it to allow only one image and look if it works then.