patch to create new image nodes in field_image.inc

-1 for using internal image function.

+1 for using internal image function.

Really. That is the whole point of the patch and it works perfectly. God this is great. I need to test it a little more; I'm not sure exactly how it meshes with the image dimension/size limitations, but this is such a great shift in concept.

About "internal functions". What I'm concerned is code like this:

+    // create a new image node
+    $image->type     = 'image';
+    $image->title    = $node->title . ' ' . $field->label;
+    $image->uid      = $node->uid;
+    $image->file     = $image->images['_original'] = $file->filepath;
...
+    _image_build_derivatives($image, true);

This assumes knowledge of internal image.module structure and unchenged working of _image_build_derivatives function. This binds us with image.module. It can change at one time without notice breaking flexinode.module. This is IMO wrong way of doing it. If we want to use image.module then image.module should be patched to provide external api-like functions.
For example I'd like to have a function for creating new image nodes, for example
image_api_create_image($name_of_uploaded_file, $title, $array_of_preffered_sizes_for_thumbs_and_previes). Such function would take care of checking if upload was successfull, copying file, creating thumbnails and should probably return node id. Next there should be functions that would return url for thumbnail/preview/full size, functions for updating image, deleting it etc.

Ok, what about a shift in goal then? I think one of the weakest areas of the current flexinode field_image is the fact that it requires the user to handle all of the image sizing. The thing I love about the image module is that it allows me to set up a CMS where all my users need to do is upload the original image regardless of size (e.g. 2000x1600px jpg), and my theme takes care of the rest.

So from that original file, it is trivial for me to provide a 200px wide thumbnail to go with the teaser view, which, when clicked, links to the extended view of the node featuring a 450px wide 'preview' image, which can be clicked to open a larger 800px wide version in a popup window. They can also click a (view original) link, which will open the _original size, whatever that may be, in a completely different page.tpl.php template designed to accommodate a huge image suitable for printing. And all of this is trivial to theme on my part.

But if I try to do this with just the flexinode image_field, I either have to make them upload 5 different versions of the same image, cropped and sized to my exact specifications, or my other option would be to use the original 2000x1600px image in every instance, and use html/css to optically scale the image; needless to say, this method has some serious performance issues.

What I have been doing — and this is such a kludge — is in the flexinode, instead of giving them an image field, I give them a text field that is merely called 'Image', where they enter in the node ID of the image they want to use. This requires them to upload the image separately, as an image node, but at least they only have to do it once. It also requires them to deal with node IDs which is lame.

This is why I was so attracted to the idea of actually creating the image node from within the flexinode admin form. It is so seamless to the user.

However, maybe these problems would be solved if there was just some way to implement size derivatives from within flexinode. Then, I could achieve everything in my above scenario with a theme template. Is there a way that we can just duplicate the image size derivatives functionality of the image node? So that for each image field, in the admin form, you could specify, not just the maximum picture size and dimensions, but also the size for thumbnail, preview, and additional derivatives as needed (even original).

I have no idea how to go about doing this, but I will do whatever I can to help. I will pay for development costs and even mock up the UI for it if that will help.

+1

If the concern is that future image.module changes will break functionality (and given that image.module was majorly revised recently, a valid one), then perhaps at the same time a patch is made to image.module to allow a true API, this can be adjusted. But in the meantime, it works nicely.

@#6:
Please see http://drupal.org/node/21979#comment-36449 - it's already implemented. I've checked, the patch still applies cleanly to 4.6 version.
Also, the patch is in cvs version of flexinode - which mean it'll probably be in the 4.7 version...

Wow Cvbge, I had completely overlooked that. But I just applied the patch and it works awesome. If you only knew how huge this is for me. I really hope this makes it in to the next release. It is so badly needed.