Killes' thumbnail patch for 4.6

Does this work ok? If so, what are the odds of this getting built into the module? The fact that the flexinode settings ask for a specific thumbnail size and even path to imagemajick, implies that they might actually be used. However, for as long as I have used this module, I've never found any evidence of thumbnail creation.

If there is no intention of generating thumbnails for images, could we at least kill those fields in the settings? I know it would have saved me a lot of futile troubleshooting and experimentation.

(Alas, I really don't expect anyone to answer or even acknowledge this comment, I just wanted to get something on the record so other theme developers don't think they're going crazy when their teasers could care less about their thumbnail settings.)

zachharkey, can you confirm that it works? If yes, I'll apply it.

This patch works in terms of generating the thumbnail file (although getting it to work on Windows required an additional modification because imagemagick tries to interpret c: in the filepath as an image format descriptor), but does not actually show the thumbnail in table view because flexinode_file_download does not accept the file when the img url loads. I am just fininshing up some pretty simple modifications to make this work. I am new to this development community; how should I proceed once I have this working? Should I post a complete patch relative to field_image.inc and flexinode.module or vs. this patch?

Thanks,
Claude

Any update on this? Looks as if it will be a valueable / must have feature. Couple quick questions.

Does the patch:
- make every image field a thumbnail (clickable to full size)?
- make an image allowed in preview a thumbnail?

Thanks,
Marand

Wouldn't it be better if this field just created a new image node? Then we could have thumbnails, we could put the image into a gallery, etc.

I have tried: it's almost working, but still have issues (due to my poor coding).

Wouldn't it be better if this field just created a new image node? Then we could have thumbnails, we could put the image into a gallery, etc.

YES! That is exactly what we need!

The biggest problem with the current implementation is that it takes no advantage of the strengths of the built-in image module. Meaning:

1. No auto resizing. All you can do is dictate what size the form will accept. This puts all the burden on the client to prepare the image.
2. No multiple sizes (thumbnail, preview, and additional sizes). Only one size is saved and thumbnail teaser views have to be faked with html percentage scaling.
3. No actual image node, so the photo is not available for galleries, comments, etc. This also means it can't be directly linked to using the image view uri's (e.g. image/view/nid/preview)
4. It makes a mess of the file system. If I have a "files" directory and a "files/images" directory, image module neatly uploads all the images into the images directory, where it stores the _original, .thumbnail, and .preview version) while flexinode has to upload directly into the "files."

As it is now, I don't even use the flexinode image fields for the above reasons. Instead, what I've been doing(and it is so backwards) is to create a flexinode textfield called "Image" where the user enters the nid of the image they want to enter. This requires them to upload the image separately as an image node, but it has all the benefits of being an image node previously stated. So when I theme the flexinode template node I control the display of the image (which is just a nid) like so:

<?php if ($page == 0): ?>
<img class="preview" src="image/view/<?php print $node->flexinode_23 ?>/thumbnail" alt="" />
<?php else: ?>
<img class="preview" src="image/view/<?php print $node->flexinode_23 ?>/preview" alt="" />
<?php endif; ?>

This method is extremely easy to theme and maintain. The problem is that it still requires too much of my clients. At least they don't have to prepare the image for upload as much, but it still requires that they leave the current page and upload the image separately, then write down the node id from the URI in their browser(I love to make the client think about node id's when all they want to do is "add a picture"), and then come back into the flexinode form and enter the id number there.

It would be so slick if they could upload an image from within the flexinode form and have the image node automatically created and it's nid saved into the flexinode object. It would be completely seemless! The icing on the cake would be if the client could choose to upload a new image or choose from the existing images, which would open a kind of thumbnail gallery (like image_assist) but when they choose the image, it just saves the image's nid into the object.

I agree that it'd be probably better to use image.module (but user comments are already available with flexinode, and the module can be fixed so it puts files into files/images dir).

For http://drupal.org/node/21979#comment-34697:
please submit a patch (instructions are somewhere on http://drupal.org/contribute).
Also, you should not use t('An ') . l(t('image'), 'node/' . $node->$fieldname) . ' has been u ... (strings concatenating), but use array method as used previously. Otherwise it's imposibile to translate it.

I could not test the first patch (http://drupal.org/files/issues/field_image.inc.patch) because I was getting "malformed line" or similar when trying to patch the file.

I've tested #5 patch (http://drupal.org/files/issues/field_image_0.inc). It still have some problems, but overall works nicely - thumbnail is generated, but when entering the posted node the thumbnail is still present. You need to click on the thumbnail to go to image node and the image is in 'preview' state. I'd like (as an option) the image to be in preview state when entering flexinode node.
[There's also the translation issue that need to be fixed]

I'm also concerned about use of image.module internal functions, like _image_build_derivatives, they should be copy&pasted into flexinode or image.module should create some sort of API...

So here's my proposition.

Thumbnails are generated using GD now, not imagemagic.

They are displayed when node is displayed in teaser mode (front page, taxonomy term listing). Had to modify flexinode.module though, not sure if this won't break other fields... The change was small, please test.

I think I'll be able to provide an example of working module, but first I'll try to add preview mode, as stated in TODO:
in teaser mode we link to full node, and in full node the image becomes a link to original image (if enabled)

There's a problem that when editing a node saving it the thumbnail is regenerated even if no new image was uploaded.

cuold yuo not use the image toolkits? hey offer very good functions, that aer installed anyway (sortof anyway)

About my previous comment:

Thumbnails are generated using GD now, not imagemagic.

This is not true. There are no direct calls to GD functions. Image resizing is done using drupal's image_scale(), which AFAIK uses whatever image toolkit you have/choose.

Here's updated patch that also generates image previews.
An example of this patch can be seen at http://graffiti.cvbge.org/

I think the patch still need changes, I'd like the original image to be available as a link below preview image, with resolution and size printed (original images can be very big).

BTW, there's a problem when using postgresql db and trying to add flexinode node:

pg_query(): Query failed: ERROR: invalid input syntax for integer: "" in ..../includes/database.pgsql.inc on line 45.

INSERT INTO node (title, uid, type, teaser, status, moderate, promote, sticky, body, comment, created, changed, nid) VALUES('Lepper', '2', 'flexinode-1', '<div class="flexinode-body flexinode-1"><div class="flexinode-image-3"><div class="form-item"> <label>Zdjęcie:</label><br /> <a href="http://cvbge.org/graffiti/pliki//tmp/IMG_0819.JPG"><img alt="Lepper" src="http://cvbge.org/graffiti/pliki/" /></a> </div> </div></div>', '1', '', '1', '', '<div class="flexinode-body flexinode-1"><div class="flexinode-textfield-1"><div class="form-item"> <label>Autor:</label><br /> Cvbge </div> </div><div class="flexinode-textfield-2"><div class="form-item"> <label>Data zrobienia zdjęcia:</label><br /> 2005.07.15 </div> </div><div class=&q in .../includes/database.pgsql.inc on line 62.

Another bug is when I enabled cache:

pg_query(): Query failed: ERROR: invalid byte sequence for encoding "UNICODE": 0xd972 in .../includes/database.pgsql.inc on line 45.

And here's a patch that prints "Get original file (xxxKB)" link below the image.

Last patch went in (to HEAD for now), with two additional '@' before filesize().

The thumbnail regeneration issue is still not fixed, but it's should not break anything.

I have several reasons to think that this should go to a separate module, not a part of flexinode.

As I understand it, flexinode manages content that have no special semantic : each fields you can define for a node have no special meaning. You can only use flexinode when the fields do not interact with each other, and do not require special processing.

The 'thumbnail' of a node have a special semantic : it's an image that represent the node, that can be shown as an icon in a node list, or as an illustration on a node page. This requires processing that image in a "special way", especially in themes. This is impossible using flexinode, because you cannot attach a special meaning to a field.

To make myself clear, I want to be able to associate an image to a node, that could be shown:

• as an icon in a node list, like here.
• can be used as an illustration on a page node, eventually in a sidebar, like here.

The best way to achive this is to use the "image" node type provided by image.module, that manages the generation of thumbnails of different sizes.

I already did some work to achive these goals.Is someone interested by that idea?

-- DamZ

The 'thumbnail' of a node have a special semantic : it's an image that represent the node, that can be shown as an icon in a node list, or as an illustration on a node page. This requires processing that image in a "special way", especially in themes. This is impossible using flexinode, because you cannot attach a special meaning to a field.

I can't agree with you. Flexinode already had a $teaser parameter which was used when displaying a field (although only in some cases; attached patch added this to most common case - when a node is displayed on main page or as a whole node). So there are already two different 'types' of display, and previously field_image had if ($brief) code.

Also, themes can react to different types of display - teaser vs full node - using css and classess (probably the code need to be added, but I think it's possibile). I'm not a themer, so please correct me if I'm wrong.

To make myself clear, I want to be able to associate an image to a node, that could be shown:
* as an icon in a node list, like here.
* can be used as an illustration on a page node, eventually in a sidebar, like here.

The best way to achive this is to use the "image" node type provided by image.module, that manages the generation of thumbnails of different sizes.

I already did some work to achive these goals.Is someone interested by that idea?

I'd be interested :)

+1 This triples the value of this module.

Sorry if this is in the wrong area but I am having a problem getting the update "field_image.inc" to work.

Applying the new field_image.inc (from CVS) works on my test site but not on the live site. Everything is pretty much identical between them. I have even checked almost every file to be sure they are the same. (Exact same Flexinode file - with & without Fleximax applied)

The Test Site (WORKING)
http://www.minifigcustomizationnetwork.com/testsite/node/11

The Live Site (NOT WORKING)
http://www.minifigcustomizationnetwork.com/node/373

When submitting a flexinode with image on the Live site it gives about 45 warnings / errors refering to various lines in "includes/image.inc" file and one warning / error refering to line 192 in "includes/common.inc". (Both sites are using the same image.inc & common.inc versions)

I am very frustrated with this mainly because it works on one site & not the other. Almost everything is identical between the sites as far as I can see.

Does anyone know what this might be? Anyone run into something similar to this before?

Thanks in advance,
-- Marand Barrientez

I did finally find the one difference between the sites. The live site has "Private Files" enabled and the test site does not. After disabling Private Files it seems to work.

Is there any way to fix this? I (and I am sure many here) would like to keep the Private Files feature enabled.

Thanks,
-- Marand B.

Hm looks like Private downloads won't work, because one function (hook_file_download()) is not implemented...
I'm looking at how hard would it be to make private downloads work.

Another very frustrating problem I have been running into is that on one type of flexinode in particular everytime I upload a jpg file the preview & thumbnail work properly, but when I "View Full Image" it returns:
The image “http://***.jpg” cannot be displayed, because it contains errors.

Has anyone else run into this problem? This does not happen on every image uploaded. Some work & some don't. :S

Also, there is an issue with one image field uploading the files ok, creating the preview & thumbnails ok then when you "View Full Image" the image size is not the full image, but that of the preview.
Any ideas?

Also, any progress with the private files issue?

Thanks,
Marand B.

Ok, I found out the solution to the problem I was having with the the images not showing up and saying "The image “http://***.jpg” cannot be displayed, because it contains errors." The problem was that the uploaded image was exported as CMYK. I changed the color model to RGB & it worked. (Yippie)

Now, I am still having an issue with one flexinode field reducing the size of the full size image to the preview image dimensions. Any ideas.

Thanks,
Marand B.

THANK YOU!!!!
field_image.inc.patch ...has made me very happy.

Flexinode obviously can stand a ton of improvement with image handling but this at least implements the intended functionality and solved a huge problem for me. I can get my flexinode themes working with proper teasers now e.g.:

<?php if ($node->flexinode_6): ?>
<img src="<?php print $node->flexinode_6->thumbpath ?>" style="border: #000 solid 1px; float: left; margin: 0 10px 0 0;" alt="" />
<?php endif; ?>

I'm still having the private files issue with Flexinode. I have private files turned on and the filepath being returned with each flexinode image field object is still the non-accessible web directory. Any thoughts on how to convert this to actually access that file?

For anyone who's trying to get images to display with private files turned on...try using file_create_url() to get the private file path.

i.e.
print file_create_url($node->flexinode_2->filepath) " />

the attached patch fix a broken link.
The problem is a conseguence of the removing of the base tag.

I applied the patch but I got tons of errors when trying to upload an image now.

I'm using private files mode on 4.6 and applied the patch from CVS ver 1.17. On saving I get

warning: imagecreatetruecolor(): Invalid image dimensions in /home/httpd/vhosts/common/drupal_4_6_5/includes/image.inc on line 221.

warning: imagecopyresampled(): supplied argument is not a valid Image resource in /home/httpd/vhosts/common/drupal_4_6_5/includes/image.inc on line 222.

warning: imagegif(): supplied argument is not a valid Image resource in /home/httpd/vhosts/common/drupal_4_6_5/includes/image.inc on line 296.

warning: imagedestroy(): supplied argument is not a valid Image resource in /home/httpd/vhosts/common/drupal_4_6_5/includes/image.inc on line 225.

warning: imagecreatetruecolor(): Invalid image dimensions in /home/httpd/vhosts/common/drupal_4_6_5/includes/image.inc on line 221.

warning: imagecopyresampled(): supplied argument is not a valid Image resource in /home/httpd/vhosts/common/drupal_4_6_5/includes/image.inc on line 222.

warning: imagegif(): supplied argument is not a valid Image resource in /home/httpd/vhosts/common/drupal_4_6_5/includes/image.inc on line 296.

warning: imagedestroy(): supplied argument is not a valid Image resource in /home/httpd/vhosts/common/drupal_4_6_5/includes/image.inc on line 225.

warning: Cannot modify header information - headers already sent by (output started at /home/httpd/vhosts/common/drupal_4_6_5/includes/common.inc:384) in /home/httpd/vhosts/common/drupal_4_6_5/includes/common.inc on line 192.

Okay, that error above was for not putting sizes as 100x80. My fault, but we still need some validation in there.

This patch makes it work for private file access. The patch is against 4-6 CVS I think. ;) This is awesome, makes flexinode great. It could still use some cleaning up I'm sure, but it's functional for private file access now.

Let us focus on the proposed feature.

We want thumbnail functionality in the image.inc. Nothing more nothing less. No private fields etc.

I want to see a new patch, updated for either 4.7 or 4.6 so that we can review. Please do not add any other features in. And do not provide a patch with all sorts of FIXMEs in them.

If I get a new patch, and a positive review and test, I will commit. If I get a proper patch, but no review, I will review myself.

Bèr

I haven't tried any but the original patch, but the original definately has a few problems. First, it doesn't use the 'l' function, which breaks sites not using clean urls. Additionally, $brief is only set in the table view. This means the original image is displayed in teasers.

I'm looking at the image field so I can use flexinode with the ecommerce module. I just want an ecommerce enabled node with flexible fields. The trouble with the current image field, even with patch, is that it still shows the field title. If flexinode gave the option of hiding specific field names, it would allow much more flexibility. I'm working on a patch with this in mind.

I would like to try the patches listed above, but first I need to know which of these is the better version so that I know which one I should patch to:

field_image.inc,v 1.15.4.1 2005/04/16 12:56:10 JonBob

or

field_image.inc,v 1.16 2005/04/16 12:54:16 JonBob

What's confusing me with those is that one has a higher version number (I'm guessing v 1.16 is a version number), but the other was submitted last (although only by 2 minutes).

I just uploaded the Flexinode module a few days ago to my Drupal 4.6.6, and it came with the field_image.inc,v 1.15.4.1 2005/04/16 12:56:10 JonBob.

Can somebody tell me which of those 2 is better?

Closing this old issue.