add_image_size support

[GoogleCodeExporter]

At the moment (version 1.7.4) the NextGEN post thumbnail integration does not 
respect additional image sizes added to wordpress via add_image_size(). Instead 
it only uses its own thumbnail size definition from the options, which was 
quite fine till WP 3.0, but could be better now. Respecting additionally 
defined image sizes would really be a great enhancement, because it allows 
flexible handling of all images with get_the_post_thumbnail(). 

Are there any plans right now to have that implemented for future versions?

Original issue reported on code.google.com by otflo...@googlemail.com on 27 Feb 2011 at 7:48

[GoogleCodeExporter]

I will have a look into it...

Original comment by alex.cologne on 4 Mar 2011 at 7:28

• Changed state: Accepted

[GoogleCodeExporter]

Any chances that this will soon be implemented?

Original comment by nowin...@gmail.com on 22 Nov 2011 at 2:28

[GoogleCodeExporter]

I will look into post thumbnails after 1.9.0 release

Original comment by alex.cologne on 27 Nov 2011 at 10:35

[GoogleCodeExporter]

Hi

Since I need this option I looked into how to change the code, and it seems to 
be pretty minor changes that we need to make to lib/post-thumbnail.php.

I am unsure if and how you want to get the changes. However, as a first attempt 
I have attached an updated version of the file which does the trick. 

Original comment by kristian...@gmail.com on 1 Jan 2012 at 9:51

Attachments:

• post-thumbnail.php

[GoogleCodeExporter]

Sorry, I pressed the save changes a bit fast. I wanted to mention that I have 
only made changes in the ngg_post_thumbnail function starting on line 69.

Original comment by kristian...@gmail.com on 1 Jan 2012 at 9:52

[GoogleCodeExporter]

I just realised that I had completly ignored the case where $size is an array 
specifying the size. So I have made some modifications so the function can 
handle that again.

Original comment by kristian...@gmail.com on 2 Jan 2012 at 6:11

Attachments:

• post-thumbnail.php

[GoogleCodeExporter]

Just updated the file. Now it is possible to change the alt and title text of 
the post thumbnail through the $attr variable, just like in the built in 
function.

Original comment by kristian...@gmail.com on 4 Jan 2012 at 6:41

Attachments:

• post-thumbnail.php

[GoogleCodeExporter]

Kristian, your solution doesn't work in my case. It even broke my entire 
ability to attach thumbs so I had to revert the whole file back to its origina 
statel (have no idea how that happened).

Alex, not only the thumbs arent working but when their insertion with fixed 
size AND crop is called by for example:
echo get_the_post_thumbnail( $post->ID, array( 300, 170, true ) );
they are displayed with reflection and watermark. Even if both of these are 
turned off in the options panel.

Any news when the fix will be available?

Original comment by nowin...@gmail.com on 5 Jan 2012 at 1:32

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Well, it works on my setup, and with this attached file the crop mode thing is 
also fixed. 

I would like to recreate your problems so I can find a fix for it but I need 
some help from you then.

If you loose the ability to even insert thumbnails it sounds more like a 
corrupted file than a problem in the code to be honest. 

Is it the same with the new file? What command do you use to insert the the 
thumbnail in your theme?

Original comment by kristian...@gmail.com on 5 Jan 2012 at 2:15

Attachments:

• post-thumbnail.php

[GoogleCodeExporter]

Kristian,

With your new file it works perfectly - no problems at all. 
Did you actually change anything?

When I uploaded the previous file, after opening a custom type post the post 
thumbnail was gone and I was unable to upload another one.

Original comment by nowin...@gmail.com on 5 Jan 2012 at 4:35

[GoogleCodeExporter]

Hi

Yes I did change some things. Mainly to solve the problem yo mentioned about 
the crop applying watermark effect.

Original comment by kristian...@gmail.com on 5 Jan 2012 at 4:57

[GoogleCodeExporter]

That's great to know. Thanks for supporting this case - I hope Alex will use 
your solution or develop his own on the next update. 

Otherwise, automatic update will once again overwrite every source changes...

Original comment by nowin...@gmail.com on 5 Jan 2012 at 5:02

[GoogleCodeExporter]

Thanks for your work. Will look into this during the weekend and add this to 
the next update

Original comment by alex.cologne on 5 Jan 2012 at 6:24

• Changed state: Started

[GoogleCodeExporter]

You are welcome, I needed the functionality anyway.

Let me know if you want it as a patch instead of the full file.

Original comment by kristian...@gmail.com on 5 Jan 2012 at 10:26

[GoogleCodeExporter]

Looks great. Fixed in r1058

Original comment by alex.cologne on 7 Jan 2012 at 2:41

• Changed state: Fixed

[GoogleCodeExporter]

In the_post_thumbnail in wordpress the size parameter does not allow you to 
specify if you want to crop the image or not. That is controlled by the 
parameter set under media->crop thumbnails to specified size.

So if we want to have a consistent behavior between nextgen and wordpress we 
need to change the behavior when we give a size array as input such that we set 
the crop to be dependent on the 'thumbnail_crop' option in wordpress. 

Futhermore I found a bug which I introduced in the last version.

Original comment by kristian...@gmail.com on 9 Jan 2012 at 11:43

Attachments:

• post-thumbnail.php

[GoogleCodeExporter]

A little more investigation turns out that the default wordpress behavior is to 
completly ignore the crop flag when used with a custom image size given as an 
array. It just scales the image.

The crop thing is apparently only used when you upload images in the first 
place. So to be honest I am not sure how we can make the behavior consistent 
and if it is wanted at all.

I think the last attached file is the closest we get to consistency with the 
current behavior of wordpress.

Original comment by kristian...@gmail.com on 9 Jan 2012 at 12:24

[GoogleCodeExporter]

Kristian, the get_the_post_thumbnail works fine when used to crop images to 
custom, not predefined sizes. Take a look at this code:
$portfolio_thumbnail = get_the_post_thumbnail( $post->ID, array( 99, 75, true ) 
);

When used solely with Wordpress, it will just generate 99x75 hard-cropped 
image. But when used with nggal, it will also generate image reflection AND 
watermark.

Although there will be usually no need to generate images like that as the 
predefined image sizes now works with nextgen, there's still inconsistency. 

Original comment by nowin...@gmail.com on 9 Jan 2012 at 1:03

[GoogleCodeExporter]

The behaviour of my wordpress is that if it can't find an image that matches 
the proportions it ends up using the generated thumbnail.

If that was hardcropped it the code you show here will be cropped. If not, it 
wont.

You can test this my changing the true to false and see that you will get the 
exact same image output. Infact the wordpress documentation for 
the_post_thumbnail specifically says that you need to input a 2 item array and 
that the crop function does not use.

The uploaded code in comment 11 should remove the reflection and watermark 
thing from the crop.

Original comment by kristian...@gmail.com on 9 Jan 2012 at 1:20

[GoogleCodeExporter]

Kristian, I just checked that when used with nextgen and the true/false 
argument for crop works. Again, this is full code that I use to display 
portfolio thumbnails:
while ( $query_thumbs -> have_posts() ) : $query_thumbs -> the_post();
    $portfolio_thumbnail = get_the_post_thumbnail( $post->ID, array( 99, 75, false ) ); // CHANGED TO FALSE TO TEST CROPPING
    $title = get_the_title();
    $portfolio_permalink = get_permalink( $post->ID );
    $thumbs .= '<a href="'. $portfolio_permalink .'" class="shortcode_portfolio_thumb '. $class .'">'. $portfolio_thumbnail .'</a>';
endwhile;

After changing the argument to false, cropping was disabled and all images were 
just scaled to fit the declared dimensions.
I just cleared nextgen cache folder and changed that argument back to true - 
now everything's cropped to completely fit the dimensions.

How do you explain that then? :)

Original comment by nowin...@gmail.com on 9 Jan 2012 at 1:35

[GoogleCodeExporter]

I explain it by the fact that I am not expressing myself clearly enough. Yes 
the crop flag works with nextgen, but it doesn't work with regular wordpress 
thumbnails. So if you have a featured image which is uploaded through wordpress 
then the crop is not dependent on the true/false you supply there. It is purely 
dependent on whether the thumbnail was cropped during upload.

So my proposal is that the code should work like wordpress does, so you wont 
notice a difference depending on where you use thumbnails from.

Original comment by kristian...@gmail.com on 9 Jan 2012 at 1:40

[GoogleCodeExporter]

Okay, now it's clear - it was just misunderstanding.

As for changing the code to work the same way Wordpress does: in general it's a 
good idea but that way the code won't be backward compatible. People who 
doesn't read changelogs and already use that cropping method might have problem 
with the fact that all of a sudden their newly uploaded images won't display as 
expected.

Btw. Alex, have you considered allowing users to choose how the image in 
gallery should be cropped, i.e. from which side should the cropping start? 
That's extremely usefull for e.g. cropping website screenshots (that should be 
usually cropped starting from bottom).

Original comment by nowin...@gmail.com on 9 Jan 2012 at 2:35

[GoogleCodeExporter]

After thinking it all through, I actually think I agree with you. It should be 
allowed to set the crop parameter as it currently is.

With that being said I still found a small bug which should be corrected.
Line 109 in lib/post_thumbnail.php should be changed from
$mode = ($_wp_additional_image_sizes[$size]['height']) ? 'crop' : '';

to 

$mode = ($_wp_additional_image_sizes[$size]['crop']) ? 'crop' : '';

/Kristian

Original comment by kristian...@gmail.com on 9 Jan 2012 at 2:40

[GoogleCodeExporter]

Thanks Kristian, I fixed that in r1059

Original comment by alex.cologne on 12 Jan 2012 at 8:41