Image module is being put into core, but not in it's current incarnation. Drupal 7 has already made several major improvements that will make handling images (and files in general) much easier, eliminating a lot of the existing code from image.module.

CCK has been moved into core, making image.module's approach to handling data "officially" obsolete. So the future of image.module is in following this trend and moving towards field-based storage.

The Drupal 7 core plan is as follows:

- Move ImageAPI into core to provide better support for toolkits such as ImageMagick (done).
- Move ImageCache into core to provide thumbnailing abilities as part of image.module (in progress).
- Move FileField into core as file.module.
- Move ImageField into core as part of image.module.

The core version of Image will basically consist of 2 things:
- ImageCache's thumbnailing abilities.
- ImageField's widget and formatters for uploading and viewing images.

The actual "Image" project will no longer contain an "image.module", since that name will be used by Drupal core. However an upgrade path will be provided to convert existing image nodes to use core's Image field. The other modules in the Image package such as image_attach and image_import will continue to live on either as part of the Image project or be split out into individual modules, but in either case be updated to work with the new field-based images.

Here are relevant action threads where this is taking place. Note that this issue is mostly announcement to image.module users. It is not an appropriate place to make feature requests or discuss the implementation of image.module in core.

Put ImageAPI in core (completed): #373613: Create "Image" Objects, Operate on Images By Resource
ImageCache in core (in progress): #371374: Add ImageCache UI Core and #491456: ImageCache preset API
FileField in core: #391330: File Field for Core

At this point it's difficult to judge everything that is necessary to upgrade to the D7 image.module, since it hasn't yet been written. Making the "image" name space available to use again is the first step in the process of making it part of core.

Comments

Thanks, Nate!

This issue serves as initial announcement and discussion place about what to do with potentially missing features of core's upcoming image.module, how to handle the upgrade path, where to move or not to move Image's sub-modules, and how to handle module dependencies of other modules.

And, it's likely that I will close this issue in ~5 days.

--

Image module itself can be understood as simple wrapper around an ImageField. It boils down to providing a dedicated content-type to access an image and manage access to an image.

Since it's a node, and the title + body of a node describe the image, it's possible to add further fields using CCK to attach more fields to an image.

Question is, whether D7's "first-class" file objects are fieldable and thereby allow for the same enhancements.

If not, the (to be renamed) image contrib module would have to provide the additional functionality.

Actually, sun brings up some good points here. I can't believe I'm actually recommending it, but it might make sense to keep an Image module in contrib that continues to offer an 'Image' node type, that, as he says, provides an Image node type with an imagefield. That would, in essence, allow other contrib modules depending on that type to continue to exist.

Of course, that's a brainstorm from having not thought much about this particular issue, and I'm not attached to the idea if other folks already have better ideas in the works.

An image module that just gives the node type would be nice.

As for other modules in the bundle:
- image_attach: this really needs to become something generic that lets you add new attached nodes of any sort, and more than one of them. There are lots of modules that try to do this kicking around but none that seems to have licked it.

If you really wanted to make an image content type live on through a module, it'd be trivial to maintain the current data structure:

<?php
$field_image
= variable_get('image_field_name', 'field_image');
$node->image = &$node->$field_image[0];
?>

Maybe some extra data conversion in there, but that's about it for maintaining backwards compatible data structures. Of course at the same time, image_attach and other modules could do this themselves and that would get them pretty far along in supporting ImageField natively in any content type.

Some more traction, please? ;) As mentioned before, I'll close down this issue, at the very least when image.module was added to core (to be expected very soon).

The primarily goal for the new Image "package" in contrib for D7 will be to provide a proper upgrade path to image fields (in core), along with a content-type. All of image module's current functionality will vanish.

I'm not really sure what to do with the additional "contrib" modules we have currently.

- image_attach: I've to admit, I never used. That's like an image field. But also allows to re-use existing images. Hence, reminds me of FileField Sources. (Hello, quicksketch? ;)

- image_gallery: WTF? I have Views.

- image_import: HAH! I did not know of, but well: http://drupal.org/project/imagefield_import + http://drupal.org/project/file_import

Speaking of Views... it might be possible that the image or file module in contrib has to provide Views handlers and stuff in D7. Given the current pace of Views in core efforts, I doubt that'll make it.

What about before Drupal 7? Is it business as usual for D6 and is it encouraged to stay with image, or to move across to some cck variant? (what about for new projects?)

I do use image attach on a site - its like a cut down image assist where the user cannot possibly get the positioning/size wrong because they do not have the option to. I like that - depending on the users, if something can go wrong, someone will surely follow that path.

I strongly agree with aaron (#2) and joachim (#3); from the user point of view, I definitely need a full-featured image node & content type; if that won't be offered by D7 core, something else should provide this.

The same goes for a mechanism for importing (image_import), bulk uploading of images, and handling images inside another node/content type (image_attach); if this could become more generic and allow for multiple image attachment it just would be great!

Image galleries can be handled through views, to that I also agree with sun (#5); replacing the image derivate mechanism from image module by Imagecache lives for a long time on my wish list, and I don't think that there will be many objections.

However, please keep a standardized image node type with a defined set of properties and a mechanism to attach existing images to other node alive...

Greetings, -asb

Image Gallery module:

In #357488: Front image must respect the sort order, salvis volunteered to create and maintain a image_gallery_legacy module in contrib. joachim currently works on Views integration in #405456: Galleries made with views. By leveraging Views, the image_gallery.module can probably nuked, because all that remains is (more or less) the taxonomy for image nodes.

I'm not sure about the right point in time for introducing/committing #405456: Galleries made with views. Currently, I'm envisioning the following:

1) Do what it takes to get to a final 6.x-1.0 release. (mainly fixing bugs)

2) Open a new HEAD/6.x-3.x branch (The current major version should be 2.x in reality), where the Image package is reduced to the max:

- Rename image.module to something else for D7 compatibility. (image_node?)
- Keep node type, CCK and Views integration of image.module.
- Merge the remaining image_gallery.module (mostly Taxonomy and Views integration) into image.module.
- Ensure upgrade path.

3) Rewrite new modules to integrate with FileField/ImageField.

- Drop custom image/file handling and CCK integration.
- Slightly rework Views integration (though I think that most of that will still be valid, since we want to work on nodes, not files).
- Ensure upgrade path.

The "Image" project/package will live on. It will just not contain an image.module.

Thoughts? Did I miss something? Any objections? Proposals?

Please help me to understand the plan a bit better. So D7 native images will not be nodes, but contrib_image will supply an image node type. Will Galleries-made-with-views work on images-that-are-not-nodes or on image nodes?

Since images-that-are-not-nodes are not nodes, they can't be controlled though node access, can they? Is there/will there be another mechanism for controlling access to images-that-are-not-nodes and to Galleries-made-with-views?

There may be a problem with image_node as a name.
I found when workingon D5 that calling a node type module foo_node led to problems with hooks and form ids and the like. Can't remember the details but maybe I filed an issue at the time... will go digging later.

Reading this thread is seriously bumming me out. I'm begging you to reconsider this.

I'm of the (strong) opinion that images should be handled as nodes, because nodes and handling nodes is the most fundamental strongpoint of Drupal overall, so why treat images differently, other than as a specific node type?

Handling images only as fields seems to trap us into an assumption that images are only to be treated as unequal, sub-components of content, associated with other single nodes of content, but what about multiple re-use / attachments of the same image to varying content throughout a particular web site? In this type of scenario, I've found that handling images via Imagefield can be most frustrating, because it means often having to re-upload images I knew were already up on the server somewhere, but had no (drupal) way of finding for re-use.

For me, from a user standpoint, the primary strength of Image, Image-attach and Image-Assist is that it's easy to find and re-use the images -- via meaningful node names rather than file names -- that I know have already been uploaded. Application-wise, it also makes more sense to be able to separate the tasks of uploading images from the authoring of content, allowing images to be preloaded and made available to content providers.

When it is desirable to maintain a field-based association for an image with a particular node, rather than uploading the images themselves to an image field, it's simple enough to add a CCK text-field and allow users to use something like Image-Assist to upload a new image -- if necessary -- or populate it with the filter tag to an existing image node.

In the overall scheme of using Drupal as a (multi-user) content management tool, training is also more consistent when end-users understand that images are just another item of content (node type) that can also easily be linked to any other item of content.

I agree with the others, above, that image galleries are not such a big deal, and can be made with Views if required, but, overall, losing the ability to manage images as nodes is, I think, a huge mistake. Personally, it will be a seriously limiting factor insofar as following Drupal's path.

Some more specific examples: We're using Image with Ubercart. I know Ubercart invests heavily in working with Imagefield, Imagecache, etc., but because of what we consider the weaknesses of Imagefield, we've modified our installation to use Image instead. This hasn't required any custom coding or module modification, but only required leveraging of the tools already available, mainly Image, Image-Assist, Image-attach and Views (for custom catalog displays, since Ubercart assumes the use of ImageField). When we upload an image of a product or a product logo as a node, that node is available for site wide use, in product nodes, reviews of the product, blogs, events, you name it, etc. That would not be true without Image, as it works today.

Essentially, in our Drupal discovery voyage, we've found that image fields are entirely ineffective and unnecessary. I ask, respectfully, please reconsider this and look at this issue more from the perspective of users of a content management tool, rather than as coders.

losing the ability to manage images as nodes is, I think, a huge mistake.

Let's step back a moment. What we've said in this issue is that the new Image module (as in the continuation of this project) *will* be "images as nodes". However, rather than having it be entirely super-hardcoded into a single content type, Image module will simply provide a node type and require an image field to be within it (which will be provided by core). So we're not losing this ability at all, we're just relinquishing the name "image" to core, which will contain the ability to attach image fields to any node type (a la ImageField) and the ability to generate reusable thumbnails for any image on the site (a la ImageCache). There's no reason why "images as nodes" needs to go away, nor any reason why image_attach couldn't work with any node-type that has an image field in it (but we could restrict it to just the "image" type if needed).

In any case, reconsidering the addition of Image module to core is too late, you might as well be asking for CCK not to be in core. The by-field management of data adds more flexibility to Drupal and isn't likely to change at this point. It only makes sense that the core module be called "image" and that it use the CCK-approach, rather than being hard-coded to a single node type.

@bryrock: There were long discussions where Drupal as a project is heading, and those in power of open source software (= those who can code) have made quite clear, that future release of Drupal (beyond D7) will become more and more CCK based, opposed to node based approach favoured so far. IMHO those two directions do not have to be opposites, however currently they are "either ... or" decisions. If CCK based content types in the future will become as flexible as node based content types of today, this future will be bright; I personally have my doubts regarding this future, considering the problems of the current CCK concept (not very robust, not very flexible, absurdly complex to manage on a database level, not very well documented, scaring off even professional software engineers, and upgrading heavily CCK-based sites is still a nightmare, and so on).

And there's another aspect of recent Drupal developments: Drupal users have a very weak standing, wishes and needs of users tend to be ignored by the (voluntary!) developers (which often refuse to solve other people's problems - that's quite understandable). However, other open source communities are much fore focused to the end user, while Drupal focusses more and more on the needs of developers (that's the ancient Content Management System vs. Content Management Framework debate). And that's what worries me most: The current image module was very much targeted to end users, very easy to use, and it was simply solving problems of users. At least it was and is solving my problems (opposed to the imagefield toybox which is technically pretty cool, but in real life close to totally useless (for me); e.g. I've never managed to understand how I could reuse data stored in a imagefield, or how I even could attach a taxonomy term to imagefield data; so far I've not even seen an approach for an asset management solution for CCK based media).

If one has a look through the CCK-based image "solutions", one might get the impression that those add-on-modules to add-ons to other contributed modules create an infinite chain of recursive problems (incompatibilites, version dependencies, abandoned modules, alpha releases...), resulting in causing problems for the end user. I'm worried that on D7 might be no working solution for my needs, just a bunch of scattered fragments only a skilled developer can patch and keep together. I hope that time will prove me wrong.

On the other hand: I'm still stuck with D5 with all of my legacy sites, so maybe I shouldn't care about other people's problems (some real fun will start when trying to migrate data from the current image.module to a CCK-based approach, have a look at 201983 and make a sandbox with real-life data to try this out ;)

Greetings, -asb

> considering the problems of the current CCK concept
Heh, now it's in core any problems will have to get ironed out once and for all :)

> The current image module was very much targeted to end users
And that actually makes it very hard to maintain: we have a big userbase, so we can't be cavalier about committing patches (the way you can be with a more techy module, and do dev releases), and on the other hand, we have very few people who test patches -- the more hardcore users all switched to imagefield ages ago.
So development goes very slowly.

> I'm worried that on D7 might be no working solution for my needs, just a bunch of scattered fragments only a skilled developer can patch and keep together
I really hope not. But as much as I am keen for image module to get to a proper 6 release and beyond, I am short on time and more hands are needed.

@bryrock: like quicksketch says, the image as node concept is not going away. This current module on D7 will essentially be a wrapper around the image field. Installing it will do the work for you of creating a content type, adding the field, giving you nice extras.
The advantages are that we get the underlying data and file handling from the field, so a heap of code in this module can be stripped out -- so gone are the piecemeal issues about file extensions, file sizes, where to save files: these are all handled in core's file field, and bugs and shortcomings will be fixed there once and for everything that uses it.
Another big advantage is that you'll be able to have multiple image content types, which can come together or not as you wish. This is something I've often wished for on projects.

I am also of opinion that the Image module as it is now should be there in Drupal 7
It is
# a very helpful and useful lightweight module for galleries
# CCK or similar Field based things will also need Views and a truck load of modules and dependencies - not resource friendly for shared hosts
# Gallery modules like Acidfree or Ecards use this, if D7 version is not available many sites will be eternally stuck with D 6
# if the proposed changes happen it is going to be very bumpy if not broken

And that actually makes it very hard to maintain: we have a big userbase, so we can't be cavalier about committing patches

There are ONLY 7 or 8 critical issues with version 6x of the image.module per se. Two of this are probably just upgrade related. Is this much of a problem to demerit a D 7 version?

It occurrs to me that when we create an upgrade path for image module, we could try to make something that's generic enough to use on other modules in a similar situation -- eg audio.
In other words, write a schema converter module, that takes as input:
- the schema function from the old image-6 module
- a schema for a CCK field
and converts the data.

+1 on #18
I had the feeling that something like this would emerge as everything gets ported to the new way. It's certainly feasible AFAIK

#17: "# a very helpful and useful lightweight module for galleries"

Second that.
A simple gallery feature should be included independently on other modules such as views or the like.

@taxoman: For gallery type things in views, please help test #470258: Groupwise maximum ('representative') relationships if you can.

I found this thread looking for a script to convert my image nodes to CCK-based nodes, so I can use the same image management (e.g. cropping) tools I already use for CCK fields. I would welcome standardization on CCK and Views. I just went through having to convert all my Event nodes to CCK, because Event Views support couldn't keep up with new versions of Drupal and Views. That experience really underscored for me the fragility of custom node modules.

I want to affirm some of the points made by asb.... As someone who has been using Drupal since 2005 and as someone who has benefited greatly from the patience and knowledge of this community, I do not want this to be misinterpreted: I AM appreciative. However, I would agree with asb that a lot of decisions are made not from a user perspective but from a developer's perspective. We are in the throes of a disaster with the image.module in trying to get it to NOT break our site as we are trying to upgrade to Drupal 6. But we've lost our images, we have only incomplete instructions on what to do about it and no matter which way we do it, the same result. I can only imagine what will happen if we decide to upgrade to 7.

Along the way, the discussion of node or not to node loses an essential point... images have been difficult to deal with for the user. They still are. And for a user who is a techie in training in an attempt to serve a community, the usability of the modules, the ease with which one can upgrade and the difficulty in finding out answers to problems is a serious, serious issue that I think should be considered by the overall Drupal community.

So I agree, changing the way images are handled by putting them into cck in 7 may work in some ways, but if there is not a continuation of the image.module system AND an improvement in how this module can be upgraded to new versions of 7 will be a serious issue to me, a user, who handles sites for thousands of students.

So, again, I realize that people have put in huge amounts of time on Drupal and its contributed modules, but please, please consider the implications for users. Please continue to develop the image.module so that it will be compatible with earlier versions AND, if you can, help a lot of us who are already having troubles in upgrading.

thanks
geoff

Geoff,

You may find this script helpful: http://drupal.org/node/432860

Or, if you still have a Drupal 5 server available, the one in this thread:

http://drupal.org/node/201983#comment-1103890

I'm not sure what the status of your image recovery efforts is, but if you can get to a point where your images are in the Image nodes again, moving them out to CCK may work better for your upgrade.

And (I've been bitten by this myself): don't try this on your production server. Copy everything to a test server, if you don't have one already, and try it there first. Or at least make a test server with the same modules and a few sample nodes to convert.

> We are in the throes of a disaster with the image.module in trying to get it to NOT break our site as we are trying to upgrade to Drupal 6.

I *think* we have have covered most of the upgrade issues. At least I thought we had.
Please check the main image 1.0 issue (linked from the project page) and see if your problems are already reported. If there are any outstanding patches, your help in testing them on development copies of your site would be very useful.

I think image module should provide only upgrade path from custom schema to field-storage. But there's a features and other modules that can help with migration!

there was a lot of thoughts about cck split but finally UI come into core...
so suppose image should end up same way but maybe become a part of some media field.

image_gallery and others should have there own projects or better to join with similar projects

On other hand making new contrib modules is wrong... there's more than enough for now

Hi Andypost.

In an ideal world in Drupal 7,
Image module would be nothing but a 'feature' within the context of 'features' module.

I can't see the 'features' model making it to core for Drupal 7.
There is some talk of 'exportables' - I'll have to read up some more.

http://www.lullabot.com/audiocast/lullabot-podcast-75-drupal-distributio...
has a good discussion on this.

@alanburke, thanx for link - really interesting... talks about exportables was a log time ago but I find nothing about in issues

Just to add, another way to replicate image_attach would be to use http://drupal.org/project/noderef_image_helper along with the nodereference module.

The other alternative is the already mentioned filefield_sources.

joachim and emdalton,

Sorry I hadn't gotten back to you sooner. We are now running close to 40 drupal sites for students and schools and so have been very busy....

First, we did all our work and do all our work on localhost sites before going to production.... Regarding the image module, I have to say that we've had some really screwy things happen, some of which I have referenced in other posts, some of which have been cleared up with newer versions.... Though we've just run into another one in its compatibility with imagex (was working fine until latest upgrade of image module).

I can say that we followed the procedures that you refer to in your upgrade. We found that in our test upgrades, we seemingly were able to get it to work, though we got multiple errors in the update process. The images seemed to be there. I will have to check our detailed notes, but when we went live, the basic result was that we lost all our images, but were able, by going backwards and then forwards (earlier version to more recent version) to recover most of them. Some exist only as thumbnails. We were so exhausted and some of the images were so old, we decided to chalk it up to experience.

Frankly, I remain discouraged by how difficult the process has been to go from Drupal 5 to 6 in many respects and discouraged by continued php errors that we are running into largely due to the fact that our main site was created with an early version of Drupal 4 and it's been a long road to 6.

I imagine that you want more specifics; we will try to get them to you now that things have settled down. We also will post something on the Image issues and Imagex issues to try to figure out why imagex no longer plunks the uploads into a default Library gallery. Users rightly feel like they upload to a great black hole. And, again, this was fine until the most recent update of Image module...

Thanks, though, for your interest and support. I hope you do not misunderstand my meanderings here; we've had tremendous help and support for what we do from the Drupal community and we understand that you all do all this work -- for us -- for free. I just happen to be a fan of the image module, but lately it has been giving us trouble.

cheers

geoff

emdalton,

more specifically, thanks for this. We currently use FCKeditor, image assist, image and imagex. We had been having good luck with that, but are now having some issues with imagex functionality after the latest image.module update.

We really have to assess where we are going to be heading with image handling. If 7 is headed to cck/filefield integration than your links will be most useful. we will test on local site and see what happens and where it leaves us. We are a writing site, but we want to get kids to integrate images into their writing to a much greater extent.

thanks

geoff

I'm going to start putting together the data migration with the help of http://drupal.org/project/field_convert

- image nodes migrate to image nodes with a FieldAPI image field.
- node types with image_attach get a CCK nodeference field.

That's great joachim. I'd love to help with that project.

Good news!

I've successfully run a test-drive conversion to FieldAPI with Field converter :D

Details here: http://drupal.org/node/757808
There's dummy data there you can use to try this out, and a couple of points I could use a hand with.

It occurs to me that another nice thing we do in image module that should perhaps survive into D7 is the derivative links in the node. I hardly ever notice them, but I've had a couple of bug reports about them (and the standard path to image files we provide too) which suggests people use them.

Which means I perhaps shouldn't have called the new module on the D7 branch image_legacy. Or perhaps I should have, and we also need an image_node module that:

- on install creates the content type and the field
- provide the standard path to image files
- provides the node links

yeah - I think that's roughly the feature-set, which we already discussed earlier?

Also, I can't recall who told me that, but I've heard rumors that image styles would be able to support custom sized images somehow (i.e. a single, individual size for a single image). The Image Assist module currently uses that rather hidden feature of Image module to allow users to create new derivative sizes for a single image on demand.

I've heard rumors that image styles would be able to support custom sized images somehow (i.e. a single, individual size for a single image)

Yes, you can use image_style_create_derivative() if necessary to generate an image entirely based an arbitrary style array that may not really exist. However you need to deal with the saving and storage of such images manually.

I've started getting stuck in :)

Some further questions that are raised by making an image_node_node_view() --

- D7 image doesn't provide human-readable names for styles. Should we?
- Should we also add an admin UI where you choose which styles are shown for image nodes?

1) #606598: Human readable image-style names - almost RTBC, but needs help

2) I'd just expose all?

1) Cool! Much more sense to have that in core. Rerolled it :)

2) If we preserve the UI for choosing whether images open in the current node or a new window, we should probably also preserve the 'hidden' option. It's certainly easy to do so. This also suggests that we need a custom image field formattter to allow a path like node/31?size=_original to work.

> So D7 native images will not be nodes, but contrib_image will supply an image node type. Will Galleries-made-with-views work on images-that-are-not-nodes or on image nodes?

I've been asked to comment on this....

> D7 native images will not be nodes

Not a valid question. D7 provides an image field. It's the same as CCK but you can put an image field on anything: term, user, node, etc.

> but contrib_image will supply an image node type

Yes. To the end-user this will work the same as image nodes on D6: you make a node and upload an image for it and that node *is* the image. Though to Drupal itself, that is a node with a single image field. But then on D6, to Drupal, it's just a node with an associated file.

> Will Galleries-made-with-views work on images-that-are-not-nodes or on image nodes?

I haven't got that far yet. But any components we provide to make galleries with Views should be reasonably reusable. For example, the gallery layout style should be generic enough that if you want to make a gallery of video nodes, or mix videos with images, you can.

Hi Joachim, just in case that you haven't run into this: Please have a look at Views Gallery and this introductory screencast. I'm using this approach when I'm forced to used Imagefields on D6 (e.g. to render images with Lightbox2) and still want image nodes plus image galleries.

Possible Drawbacks:

  • Imagefield-based nodes are not supported by input formats like PEAR Wikifilter or mediawiki_filter;
  • the galleries are not based on taxonomy (but on Views Attach plus Nodereference URL - quite generic tools);
  • 'Views Gallery' galleries are not significantly more flexible than taxonomy-based ones; i.e. selecting a larger cover image or mixing images with different sizes on one page isn't supported, at least not out of the box;
  • galleries of galleries are currently not yet supported (but some workarounds are floating around).

However, this approach works fairly robust, and doesn't exclude (additional) taxonomy-based galleries (thanks to views 2). Maybe "just" providing a migration path to 'Views Gallery' would ease the conceptual work for 'contrib_image'?

Greetings, -asb

Honestly I think Node Gallery is a completely suitable replacement to the current Image Gallery module included with Image module. It's basically an advanced Node Reference field where a "Gallery" node type can be set up that references individual image nodes (using ImageField). I like this module especially because it can be configured to use any node type as a gallery, any node type as an image, and use any imagefield within that node type. Plus it has all the niceties of some basic theming and excellent Views support.

subscribing

Joachim,
I don't want to sound negative, but I think that we may have to consider the possibility that Media module will become the de facto standard for image handling in Drupal 7. I think that it's support by JacobSingh from Acquia and inclusion in Drupal Gardens guarantees it's place, even if Media is not an official core module. Images are promoted to being the equivalent of nodes, not just being attached to nodes. To quote Aaron Winborn:
"This allows Media asset objects to be a first class Drupal citizen, alongside Nodes, Users, Taxonomy, and Comments."

Are you referring to Media by Aaaron? The usage stats are currently reporting 40 (fourty!) users. For 'image' they currently report between 64,421 (May 30th) and 75,701 (May 23rd) installations. I don't know how accurate those stats are, but prognosing a 'de facto' standard based on this figures sounds a bit far fetched to me...

Why wouldn't the model Gallery Assist provides work for Galleries?

Yes asb, Media module. Of course you could be right, and Media could be a complete failure. If people are happy to keep using their traditional image node model when they upgrade to Drupal 7, then that's what they will do. Usage of Media module would be low at the moment as not many people have live Drupal 7 sites, whereas Image module has been around since when?

I guess I'm thinking more about new-comers to Drupal, as Dries is claiming that there are already 10,000 sites on Drupal Gardens, and by default they are all using the Media module. Sites on http://www.drupalgardens.com may be exported at any time to a stand-alone Drupal 7 site, and they will already have something called an 'image' installed by the Media module.

I don't think comments can be attached to anything but nodes for Drupal 7, so as an upgrade path atleast, it would be better to upgrade to imagefield nodes as it will be consistent with what was present before.

For new sites, they will have an option to use either and by D8 Comments will probably be able to be used on any entity type.

Media module still lets you make images as nodes -- it provides a Media field you can add to nodes or any entity. It also declares the files Drupal knows about in its {file_managed} table (the equivalent of D6 {files} as entities, which are therefore fieldable too.

I'm unconvinced by it -- because it doesn't seem to me that these two things belong in the single module -- but obviously having one common system is much better, and if that's the way things are going then we should focus the upgrade path in that direction.

It's not that much of a change though -- it just changes the field we migrate to. We could possibly even offer it as a second option.

If we want to preserve other features of image module we still need a wrapper module here.

joachim: It also integrates an embedding system for media entities (like inline) with wysiwyg integration, display of these entities (like emfield), remote media, metadata for files, a dialogue to browse for existing files, and, last time I checked, even a small gallery module with slideshows. It's very ambitious, which might be a risk, but also a blessing if it works out. IMHO, it's way way way too early to call it the de-facto standard for D7.

Comments is only stopper from using Image as self-entity... I think all extensions like fivestar, bookmarks should be attachable to any Entity so Image could live as lite-entity.

With upcoming patch #796658: UI for field formatter settings I think is most promising solution for D7 galleries is Gallery API

subscribing

subscribing

joachim pointed me to this issue from #486546: Image 1.0 when I asked what the future for image would be after 1.0 now that D7 is on the horizon, but he said it needed a summary. I agree :)

Would the summary be something like this:

a) There is an upgrade path to turn image nodes into a D7 content type with an image field. (link?)
b) Other features provided by the image module (derivative links, gallery) will still be available in D7, but the image.module name has been yielded to the D7 image field module.

The one part that I didn't see mentioned was a replacement for Image Import, which is my favorite part of Image module, since I primarily use Image module rather than ImageField when I have a large number of images to imort. Did I miss it, or is that yet to be done?

After a summary of this issue has been made, can it be turned into a handbook page & linked from the project page? (I might have time to create the handbook page, but I'd need to know more details first.)

> a) There is an upgrade path to turn image nodes into a D7 content type with an image field. (link?)

see #32 above and the D7 checkout of image module.

> b) Other features provided by the image module (derivative links, gallery) will still be available in D7,

Provided someone writes them. I'm really really short on time to devote to this. This will only happen if people post patches!

> The one part that I didn't see mentioned was a replacement for Image Import, which is my favorite part of Image module

Yet to be done, and should almost certainly be redone as something much more generic for the FieldAPI file and image fields.

Good summary, thanks :)

Was already mentioned back in #5: There are

- http://drupal.org/project/imagefield_import
- http://drupal.org/project/file_import
- http://drupal.org/project/node_import

and I think that one of them should be the new home. Actually, I think that the community should join efforts on a (re-purposed) project like http://drupal.org/project/import, as I don't think it matters at all into what kind of thing you are importing (entity/node, field, file, etc.). Apparently, the Import module project page mentions that people should use Migrate instead, but I'm not sure whether Migrate really does the same...?

Migrate seems to be more about creating nodes from HTML pages, etc. from a brief look at the project page. I think Image module's users would be overwhelmed by its complexity and requirements in terms of other modules.

I'll take a look at the modules you mentioned, sun.

joachim/sun: I'll try to post a handbook page summary soon and link it back in this issue so you can add it to the project page.

Migrate is great for getting data from alien tables into Drupal. However, it's really no good at all for importing stuff that's already Drupal -- that's why there's modules like Content Distribution. And yes, given the use case 'I have a heap of image files and I want them in Drupal', Migrate does nothing much for you at all.

There is a new Plupload integration module to upload multiple files, already being used by Media Gallery. The beauty of Plupload is that it can present widgets in Flash, Gears, HTML 5, Silverlight, BrowserPlus, or HTML4 depending on the capabilities of the client computer. There are versions for D6 and D7.

And there are Flickr Sync, Flickr Rippr and Flickr Batch Import modules that specifically import Flickr photos. Feeds can also be used for importing media.

please note that the current migration of image module to core fails, until #933498 is committed. (patch needs review)

> current migration of image module to core fails

What current migration of image module to core?

> current migration of image module to core fails
> What current migration of image module to core?

I guess this one?
#757808: Image module migration at Field converter module.

Is there any upgrade path yet? Upgraded a dev site today and image fields are irretrievably borked. CCK's content_migrate module seems to be looking for the old image and imagefield modules, which can't be enabled in Drupal 7.

If you were to do this on a production site with a lot of images, it would be a nightmare.

There WAS an upgrade path, with http://drupal.org/project/field_convert and the 7.x branch of Image module (ie this project). I've not tested it for several months -- it would be very useful if people tried it with real data.

I installed field_convert, but I've got no idea how it is supposed to work, is there any UI for it?

Not sure it will work for me at this point anyway since I already did several things that may have irretrievably messed up my image nodes.

Instructions here: http://drupal.org/node/757808

FYI, the instructions refer to installing "image_legacy" module, no idea what this is (was?) or where to get it. The instructions in that thread seem like they reference some previous conversation.

However, another problem to be aware of if you're upgrading right now is that you'll need to apply the patch here:

http://drupal.org/node/933498

or the first time you attempt to change an image style you'll have errors all over the place.

jenyum,
I think that "image_legacy" module was just to emulate Image module for testing, but if you have a D6 website, then you already have a legacy image module!

image_legacy is *this* module, renamed to prevent a clash with Core image on D7. Get the 7--1 branch of this from CVS. I've amended the instructions over there too.

Subscribe.

turn this module into a D6 to D7 image importer and also a generic image importer/exporter tool, complementing the new image (imagefield) module in D7, as a contrib module.

or else... kill it ;)

as comparison, CCK was merged into D7, but the module still exists and was turned into a contrib module in D7, and now holds misc stuff that did not get in, and possibly might hold new stuff in the future.

People interested in the upgrade path should look at http://drupal.org/node/757808, where there are bugs to iron out.

I think for this issue we should list the current features image D6 offers around images, and consider which of those are useful and should be kept, and which of those are possible with other tools.

subscribing

list the current features image D6 offers around images, and consider which of those are useful and should be kept

  • Image nodes (a node type containing an image field).
  • The non-views image_gallery module.

Both are needed for migration and as a zero-effort starting point for getting images on a site.

#76/@salvis: second that.

@salvis: Just for better understanding:

What is 'Image nodes'? Are you referring to Node Images?

After having based all 'image' module galleries on Views, what would be the advantage of reverting to the pre-Views era by utilizing the "non-views image_gallery module"?

More interesting would be the question if there is anything even remotely comparable to the 'image_attach' (re-usable image nodes) in the imagefield world...

@asb:

What is 'Image nodes'? Are you referring to Node Images?

No, if I was referring to Node Images, then I'd call them Node Images and I'd go to the Node Image queue.

'Image nodes' are what you quite naturally refer to as 'image nodes' in your last sentence... It's the content type defined by the D6 Image module. I have a D6 site with roughly a thousand of these, and if node/1234 is one such node, then I'd like to find that node again under the same path after upgrading the site to D7.

After having based all 'image' module galleries on Views, what would be the advantage of reverting to the pre-Views era by utilizing the "non-views image_gallery module"?

If you have "based all 'image' module galleries on Views," and you're happy with them, then there's no advantage in "reverting to the pre-Views era."

But if you have not, then there's no advantage to installing the Views monster either. As I wrote in #76, pre-Views image galleries are needed for migration and as a zero-effort starting point for getting images on a site. I'm still convinced that the pre-Views image galleries are easier to install, configure, and run — they simply work.

Image_attach can be replicated well using nodereference and a few helpers.

http://drupal.org/project/nodereference_explorer provides a good add-on to help you select the right attachment - form EXISTING images.
Need a different module ( like http://drupal.org/project/noderefcreate ? or one of a few others - nodereference_autocreate autocreate noderelationships in that family) to create new ones on the fly. ... though we need a solution that doesn't have all the dependencies these ones do

Some effort is needed to make the widget behave nicely, though it can be done.
It would be a custom view + cck field + form alter job, but a replacement for image_attach is certainly do-able.

Well let's get the list complete before we debate it.

Image module:
- I1: an OOTB image node; that is, on install, creates an image node type with an image field
- I2: a standard path to image files
- I3: node links to view other derivative sizes
- I4: human-readable labels to image derivatives (sadly this didn't make it into core D7)

Image attach:
- IA1: a way of attaching image nodes to other nodes
- IA2: an inline form to create new image nodes on the fly while creating/editing other nodes, specifying just title and file
- IA3: allows restriction of attaching form to either just new nodes, or just existing nodes.

Image gallery:
- All doable with Views. I consider this a moot point. If this needs debate, I suggest a separate issue for it.

Image import:
- Should be all doable with generic import modules.

Imagemagick:
- unsupported.

Please review the list above and suggest additions and amendments.

Now here's my thoughts on this:
- I1 is probably important.
- I2 - does anyone use this at all? I barely remember it exists.
- I3, I4 - might be nice; the two go hand in hand to my mind.
- IA1: nodereference. But...
- IA2: needs investigation. Note the extra requirement in IA3 -- this is actually pretty important. For example, on a site like drupal.org, it's the ability to impose this restriction which prevents project owner A from attaching the image from project owner B's project to his own.

@salvis (#79): "I have a D6 site with roughly a thousand of these, and if node/1234 is one such node, then I'd like to find that node again under the same path after upgrading the site to D7." - definitely yes! If the non-Views galleries really need to be migrated, that's indeed a separate issue, as Joachim suggested.

@joachim (#81): "Imagemagick: unsupported". Imho that would not be so good since at least Debian comes by default with a lib which makes status report to complain ("The GD Library for PHP is enabled, but was compiled without support for functions used by the rotate and desaturate effects..."). However, shouldn't this be a problem for Imagecache to take care of?

Regarding the list about things for 'Image legacy' to take care of: I remember vaguely that the ("old") image module made some adjustments in taxonomy for 'Image gallery'. Is there something that needs to preserved/added when migrating to D7 taxonomy?

Re IA2: How important is the inline form to create new image nodes on the fly while creating/editing other nodes? On my D6 Imagefield sites I'm using either the Node Reference URL Widget (two steps to create a referenced node) or Node Relationships plus Modal Frame API (creates new to-be-referenced nodes "on the fly"). There's also a Modal Frame CCK Editor which "opens edit forms for selected CCK fields or field groups in modal frames from the node view. Could a modal frame or a similar mechanism (ctools) be an easier to implement alternative to an inline form?

Image (node) module:
- I1: an OOTB image node; that is, on install, creates an image node type with an image field
- I2: a standard path to image files
- I3: node links to view other derivative sizes
- I4: human-readable labels to image derivatives (sadly this didn't make it into core D7)
- I5: Custom image derivative sizes per image

I1 is the primary functionality we need to retain in its basics short-term. Nodes provide a canonical URL for an image, node access, and allow to enhance images with fields. In the long run, images should not be nodes (they are not "content"), but entities instead. For that sake, a basic port to D7 should be sufficient, whereas the community effort should be to migrate image nodes over into Media module or similar modules; special-casing images just because they are images and not some other media doesn't make too much sense.

I2, no idea, never used, drop it.

I3 doesn't sound that important, so could be deferred to later. Basically a hook_field_attach_view_alter() for the locked image field on image nodes to append the links, and some hack that acts upon field's 'prepare_view' operation to grab the image style name from the URL and put it into the field display settings.

I4, not sure how urgent this really is. I've seen and reviewed the core patch a couple of times. Most likely depends on whether we do I3 and postponed on that.

I5, however, is one important detail of Image module that not many know of. For example, the third-party Image Assist module (and perhaps others?) makes heavy use of this feature. Image module allows to create custom image derivative sizes for a single image (e.g., druplicon.custom-143x126.png) on-the-fly in the file system, and permanently retains those derivative sizes (also with a db-level entry), until/unless the image node is deleted. From all Image module features, this is the one I'm worried about most. AFAIK, Image module is the only module on d.o that provides an interface to do that. Without it, we are doomed in a world of always identical image styles/presets.

Image attach:
- IA1: a way of attaching image nodes to other nodes
- IA2: an inline form to create new image nodes on the fly while creating/editing other nodes, specifying just title and file
- IA3: allows restriction of attaching form to either just new nodes, or just existing nodes.

Honestly, this entire functionality belongs to more generic Relation, References, Node Relationships, and all the other modules. If I'm allowed to vote, then I'd vote for not porting Image Attach at all. Instead, let's figure out a migration path to one or more of those modules.

Image gallery:
- All doable with Views. I consider this a moot point. If this needs debate, I suggest a separate issue for it.

I agree, especially as the views integration reduces maintenance burden for the Image project. It's always easy to claim that the custom solution is sufficient (and perhaps even "better"), if you don't have to maintain it.

Not sure what you thought of, but it looks like we could drop the separate image_gallery.module and just keep the default views and any other potentially required views customizations in image_node.module.

Image import:
- Should be all doable with generic import modules.

Agreed, total cruft. (even though I copied some of that code as template for a custom import script last year ;)

Imagemagick:
- unsupported.

Yes, this needs a new dedicated home. Ideally http://drupal.org/project/imagemagick should be taken over. I'm going to kick-start that takeover process right afterwards.

However, the fundamental bottleneck seems to be that there are no contributors that have real (own) interest in ImageMagick, AFAICS.

I've just contacted the owner of http://drupal.org/project/imagemagick and requested a project takeover, which originally was a GSOC project that was never completed, Heine told me in IRC. If he doesn't respond within the next days, I'm going to take over the project as intermediate maintainer (don't plan to do anything with it though).

Furthermore, I was under the impression that http://drupal.org/project/imageapi was moved into D7 core. There is however a dev snapshot for D7, which (also) contains code for ImageMagick support, and other stuff, status unclear, drewish not reachable. It is quite possible that instead of moving our code into the ImageMagick project, we'll move that code instead.

for IA1 and IA2 (or image attach replacement), there is the noderef_image_helper module that provides the necessary widgets (but has not yet been ported to Drupal 7).

Image gallery:
- All doable with Views. I consider this a moot point. If this needs debate, I suggest a separate issue for it.

I agree, especially as the views integration reduces maintenance burden for the Image project. It's always easy to claim that the custom solution is sufficient (and perhaps even "better"), if you don't have to maintain it.

I've volunteered to maintain it before, more than once, but I never got any substantial response...

Not sure what you thought of, but it looks like we could drop the separate image_gallery.module and just keep the default views and any other potentially required views customizations in image_node.module.

If there's interest in pursuing this then I'll be happy to open a new thread and look into it again. OTOH, if you're determined to kill it anyway, then just say so here and now, and we can save the effort.

@sun: I'm thrilled to see you mention the Image Assist module — can we hope to see it again in D7?

> - I5: Custom image derivative sizes per image

Yup, I was totally ignorant of that. In fact, not entirely sure what it means! How would that work with the D7 system of image styles?

> Honestly, this entire functionality belongs to more generic Relation, References, Node Relationships, and all the other modules. If I'm allowed to vote, then I'd vote for not porting Image Attach at all. Instead, let's figure out a migration path to one or more of those modules.

For the data handling, yes, absolutely. But I've yet to see decent UI for node-in-node creation. And this is currently a feature of d.org itself.

Image Assist module — can we hope to see it again in D7?

The future and porting of Image Assist completely depends on Image module. However, it's relatively clear already that it's going to require massive changes, which will ultimately duplicate the goals of Media and Inline modules. It will take some time, unless there's going to be serious funding.

How would that [Custom image derivative sizes per image] work with the D7 system of image styles?

AFAIK, not at all. That's why I steadily tried to bring up this detail in all related (core and non-core) discussions all over again. @drewish once mentioned to me that it might be possible to do, but so far, I wasn't able to identify a reliable and scalable way that doesn't involve to create gazillions of additional custom one-shot image styles/presets. Perhaps that's possible and the way to go, but likely requires to setup an own storage and handling for custom image styles, so they don't appear in the regular image style administration and similar issues. And perhaps we need to move this functionality into a dedicated image_style module...

For the data handling, yes, absolutely. But I've yet to see decent UI for node-in-node creation. And this is currently a feature of d.org itself.

I'm pretty sure that d.o will convert its image_attach data into image fields on project nodes. d.o doesn't have the use-case of re-using images, which makes the essential difference for most users of Image module.

re - I5: Custom image derivative sizes per image
When I've needed to do this, I've used the Image Resize Filter module. It automatically creates custom sizes for inline images based on their width attribute, and saves the new images in the /default/files/resize folder. And it has already been ported to D7.

On a side note, I've got the migration of 'classic' image nodes to imagefield data working again (see #757808: Image module migration) -- however, there's a critical core bug that means customizations to the image node type are lost: #895014: All fields of a node type are lost on module disable.

Decision on ImageMagick now available: #1028876: Future of ImageMagick toolkit

ever since i've been testing Drupal 7 (alpha6), i've been including ImageAPI in my tests. it has also been a part of all my Drupal 6 setups as well. though i haven't used ImageMagick, therefor always relying on GD, i'd assume it works off the box with ImageAPI module.

from the module page, current version:

ImageAPI 7.x-1.x-dev ImageAPI supporting multiple toolkits.
ImageAPI GD2 7.x-1.x-dev Provides additional operations for PHP's built-in GD2 image processing support.
ImageAPI ImageMagick 7.x-1.x-dev Command Line ImageMagick support.

from the project page:

ImageAPI 7.x-1.x-dev tar.gz (22.9 KB) | zip (32.74 KB) 2010-Oct-18
"Drupal 7.x
#D7CX: Most of the code from ImageAPI has been moved into Drupal core in 7.x. Under 7.x this module provides an ImageMagick toolkit and extends core's toolkits too add an unsharpen mask action."

i'd say keep evolving ImageAPI and merge in ImageMagick to it (if at all).

to my understanding, ImageAPI name came from the idea of making a module to work with both GD and ImageMagick, so you don't need to have two modules for that, each with their supported modules, but only one...

Drupal 8 ffs should meanwhile absorb the remaining code and the support for ImageMagick.

#475774: image attach: the future has been marked as duplicate of this issue; contains some further details (wishlist) about Image Attach functionality. But as mentioned before, limiting this kind of functionality to images doesn't make sense in D7 anymore.

Subscribe.

Now the Field Convert works again, perhaps someone might like to take a stab at writing the conversion plan for Image Attach data to nodereference data?

@sun: Been thinking about what you said about calling the new module image_node. You're right, we should at least try it on D7 and see whether the name works.

Why image_node and not node_images which still have no D7 version

Because it's an image node, singular.

> node_images which still have no D7 version

That could probably be another candidate for a Field Convert migration plan.

Hi all!
Right now, the only thing that keeps from upgrading my production sites is the lack of clear information on how to upgrade the nodes containing images, made with the image module in 6.x to Drupal 7.x

Creating a content type called image gives the nodes their proper content type names back, but the image files are not even conscidered as attached files.....

Would you guys be so kind to write us a little upgrade proceedure once you've find out a proper sollution?
Or let me know where to find it if you ahve already made one? I would love you to the bone even more than I already do! :)

Hi all again,
I'm not sure where to put this, but it seems even the image handeling of drupal would benefit from a proper file-management system.
Like entering the file name and media type somwhere in a table of the databass?
Then have a field that works like a selection window displaying the files in the system, where you can filter out media types in the different content-types of drupal.
displayin to the end use something like in the "attach existing images" function of the image module?

just bouncing ideas...

@Sakrecoer: There are other modules (IMCE FileBrowser, possibly Media module) which can help you get the workflow you desire. Keep this issue focused only on the discussion of an upgrade path for the modules in the Image module package.

> Right now, the only thing that keeps from upgrading my production sites is the lack of clear information on how to upgrade the nodes containing images, made with the image module in 6.x to Drupal 7.x

There's a working upgrade path for your data. I keep mentioning it, though perhaps there should be something on the project page. It's at #757808: Image module migration.

> I'm not sure where to put this, but it seems even the image handeling of drupal would benefit from a proper file-management system.
Like entering the file name and media type somwhere in a table of the databass?

That's been around since D5 at least... look in your database's {files} table ;)

Thank you very much for the precious information. I must say i'm completly lost arround here since the big upgrade, so my appologies if i'm being off-topic.

Not at all; it was a good reminder that this needed explaining clearly somewhere prominent. Report any problems you find on #757808: Image module migration! :D

So now we have git...

Should we rename the image_legacy.module I made on the 7 branch to image_node.module?
Or will this live in a new project on d.org?

Well,
What people expect to do (quite reasonably) is go to http://drupal.org/project/image and click download image7.x.3 and get on with their upgrade. They will expect all their images and galleries to be present as they were in D6.

The closest to this behaviour as possible will mean the least confusion for people, and the least number of support questions for you.

Let's rename it and keep it in the Image project for now. Changing/moving projects adds a lot of bureaucracy/overhead and needs careful planning.

> There may be a problem with image_node as a name.
I found when workingon D5 that calling a node type module foo_node led to problems with hooks and form ids and the like. Can't remember the details but maybe I filed an issue at the time... will go digging later.

... and there still is a problem.

The way the node system works is this:

- your node type is called 'foo'.
- when you add or edit a node, node_add() tries to get the form 'foo_node_form'.
- this does not exist, so the FormAPI looks for it in hook_forms() for a builder function.
- node module's hook_forms() supplies it with 'node_form' which is a common builder for all node types.
- node_form() creates the basic form, then invokes hook_form() to get anything special the module wants to put in.
- hook_form is built using the *base* which may or may not be 'foo'.
- if it's 'foo', then the function is foo_form().
- if it's 'foo_node' then the function is foo_node_form, which breaks step 2, because that is the form builder name that is *supposed* to be absent. If it exists, you get a broken form.

So we if we call the module image_node, the base MUST be something else, because 'image_node' will break the form.

How about 'image' as base?

But then we get a clash from core's image stuff:

Array to string conversion in image_get_info() (line 126 of /Users/joachim/Sites/7-drupal/includes/image.inc).

This is because image_load exists in image.inc, and node module sees it as hook_load.

So:
- we can't have a base of 'image'
- we can't have a base of 'image_node'.

Suggestions?

good use case for magic__underscores in the hook system...

The more that I reread all the above, the less sense keeping the image/image_node name makes. At #4 quicksketch pointed out that image.module for D7 consists of two lines of code, so can't really live by itself.

Would it not be true, that the vast majority of image.module users, really want an image gallery? They probably couldn't care less that this requires an image node; they just want some method of displaying their photos to the world, sorted into albums/galleries.

So why not just start a new Image Gallery module? Namespace would then be image_gallery and probably image_gallery_node. Then proceed with the points made in #9. That would give some purpose for the module to continue to exist, give an obvious upgrade path for past users of the module, and show up easily in module searches. I know that if I was searching for a new module to add to my site, the first words I would try are "image gallery".

@Scott: Please reread #4 and get your facts straight; quicksketch was talking about an hypothetical image content type. We know now that it isn't quite as easy as quicksketch quickly sketched in 2009. Actually, image.module in D7 is not really small:

./modules/image# wc -l image.module
1135 image.module

And yes, some users are using D6 image.module because it builds image nodes. That's the whole point of this discussion.

OK, but #107 asked for suggestions other than image and image_node. My suggestion is image_gallery_node.

But if it needs to be independent of image.gallery then maybe image_content? What about image_base or image_core?

http://drupal.org/project/media_gallery and a dozen other modules already fill the role of an image gallery so well without more clutter.

mmm...
And if Media module provided an upgrade path from Image module, to convert D6 image nodes into D7 media entities, as suggested up at #83 ...

... then we wouldn't need this conversation and we could let Acquia worry about it ;-)

Just to confirm what asb said, the reason I found and used image.module Drupal 5 and 6 was because I wanted images to be nodes. I sometimes replaced the gallery functionality with a custom solution, but the basic functionality of having image nodes was important for me.

Media module does look pretty nifty - you get fieldable media & an output path to present them should you want to. (Though I think fieldable files should have been a separate module, because if you just want to add fields to PDFs, you don't need the whole media overhead.)

> if Media module provided an upgrade path from Image module, to convert D6 image nodes into D7 media entities

Field Convert module moves data from an entity to itself, but it probably could have the ability to move data elsewhere added as a feature.

> we could let Acquia worry about it ;-)

??
Are Acquia offering to help? That would be awesome, as we have some 80k users stuck with an upgrade path that's still in alpha at the moment.

It is not an appropriate place to make feature requests or discuss the implementation of image.module in core ???

Eh?
It is no possible discute for images module D7 in this forum ?

and where I go for know this .. in one wordpress blog ?

It's a big problem dont have this important module for upload image in ftp in drupal 7 !

-- a good days --

> It is not an appropriate place to make feature requests or discuss the implementation of image.module in core ???
> It is no possible discute for images module D7 in this forum ?

Let me explain once again: Image in core and the image project you find at http://drupal.org/project/image are TWO COMPLETELY DIFFERENT THINGS. That is why we're not discussing image in core here.

> It is not an appropriate place to make feature requests or discuss the implementation of image.module in core ???
> It is no possible discute for images module D7 in this forum ?

Let me explain once again: Image in core and the image project you find at http://drupal.org/project/image are TWO COMPLETELY DIFFERENT THINGS. That is why we're not discussing image in core here.

True enough, but it is the image project that, under the "Upgrading" heading, has the link back to this discussion, and this discussion begins right off with the proposition that the image module was being put into D7 core—but not really.

IMHO that's been the source of the confusion and angst in this now nearly two year discussion. The D6 image module has/had definite strengths, some of which, I think, go well beyond image galleries, and those strengths are not present in D7 core, even though something being called Image is. I keep seeing that image gallery argument, pre-supposing that that is what most people use the image module for. That may be statistically correct, but overlooks other strengths. For me, the main strength of the D6 Image module is being able to quickly find, access and re-use images that have already been uploaded or imported in batches. Combining Image with its add-ons, mainly the import and attach, and also other complementary modules such as Image-assist, made it easy to come up with intuitive user recipes for image handling in a variety of content-types. Whether using image attach or image assist, when users are adding images to new content as they compose, they can find out if that image already exists as a node in their site collection (whether it appears anywhere in a gallery or not). Image fields, whether in a custom image content-type or as fields in other content-types, don't provide that feed-back, so users tend to upload and/or re-upload images for every single or repeated use. Even when they know with certainty that they've previously uploaded a particularly image, they don't know how to find it without leaving the content composition they want to add it to, so they upload it again (and again, and again).

It seems more than obvious that there should be some image handling functionality in core, but IMO it would be the functionality of the D6 image contrib module.

> For me, the main strength of the D6 Image module is being able to quickly find, access and re-use images that have already been uploaded or imported in batches.

It may be this can be done with the new Media module, and also with Filefield Sources.

However, I do appreciate that there is a huge userbase already with the images-as-nodes system. And there will for the time being at least be things you can do with images-as-nodes that you can't with D7 file entities (comments being one).

Upgrading this project to provide the images-as-nodes system on D7 can happen, but this needs people to step up and make it happen -- in other words, post your patches please! :D

subscribe

Let's get back on track. The thing to deal with first is outlined in #107. Suggestions please.

imagenode
emage

From joachim's #107:

- we can't have a base of 'image'
- we can't have a base of 'image_node'.
Suggestions?

My2c:

  • Salvis' suggestion in #122, "imagenode" is interesting and quite suitable, but I wonder if it will create confusion and even potential unnecessary typos and bugs later on? Reading code and finding "imagenode_node_node_view" requires a re-read and increased concentration to make sure what you see is correct or not. Perhaps "imageasnode" or something like that, just to clearly distinguish it from "image_node"? And the basis name should not include underscore character.
  • "img" or "imgnode" ?
  • or "imagewrapper" or "imgwrapper"?
    (Ref. Sun's comment in #2 above: "Image module itself can be understood as simple wrapper around an ImageField. It boils down to providing a dedicated content-type to access an image and manage access to an image.")
  • "imagetype" ?
  • "imagehub" ?

Ideally, the name itself should have a resemblance as to what makes this module unique.
Every time someone sees the "add xxxxxx" or where node type names are displayed in lists or tables, this name should automatically trigger an association as to what is the rationale in using this one instead of its alternatives.

Perhaps this project should also be continued over at a new namespace with the same name as what is chosen for the image type name here.

I'm sad that the Image_Gallery hasn't been ported to Drupal 7, but I get that. I mean no web site is going to exist today in a text only version and "image" means a good deal more than "gallery".

Although, I also don't want to be in Drupal 6 forever, but I'm not a programmer. I "need" a gallery module that can:

Provide nested image galleries like the Image_gallery module did (I have well over 200 galleries currently)

Provide subscriptions per gallery (I use taxonomy terms and the subscription module in D6)

Provide the ability to import/upload many images at once, I usually upload about 100 a time (I host 10,000+ currently)

Is there a module that can replace the image_gallery module in these ways? (I've tried every gallery type module I can find!)

> I'm sad that the Image_Gallery hasn't been ported to Drupal 7, but I get that.

Please understand: image_gallery would get ported to D7 if people who need it like yourself roll up their sleeves and put in the work. I can't stress this enough: THIS MEANS YOU ;)

'Image' module is a typical user module, primarily used by site builders, because it is kind of user friendly and works out of the box. Most users of 'Image' module are no code developers and simply want to manage images. Probably lots of users of this module are not even aware what a patch is, left alone being able to contribute one.

Since we probably could as well wait for Godot as hope for substantial community contributed code, I'd suggest to set up some kind of chip-in widget and fund the development of the missing pieces. With something around 80k installations the user base should be large enough to get some money together and sponsor what the maintainers can not lift in their spare time. What do you think, Joachim?

Well, wysiwyg module has 118393 users -- slightly more than image -- and I'm not sure its maintainer managed to raise that much with a chip-in. So I'm sceptical of how much that would raise, but I'd be happy to give it a go.

joachim, Much of drupal is geared towards programmers, but I have found many users are not programmers. I am one such user. I have donated money to drupal.org and a single project, so I don't consider myself a freeloader but I have not donated code. I have messed up the basic themes by editing the php for my own interest. I have installed drupal 6 seven times and spent well over a year attempting to get a site running through trial and error. I don't find it very user friendly at all. I know some database concepts but ZERO php code at all. I liked the image_gallery portion of the image module because it was a 'one stop shop' for all my needs.

My post was to support the concept that there is a need for the image_gallery in drupal 7, not others like the "node gallery" that others that have been tossed around as plausible alternatives. I have not yet found a plausible alternative to the image_gallery for drupal 6, but I have high hopes that something could be done for drupal 7.

Please do not assume that every user is a programmer.

Now if someone wants to set up a donation site with clear plans on the creation of a module, I'd be glad to donate!

re. http://drupal.org/comment/reply/513096/4230496#comment-4230496

So:
- we can't have a base of 'image'
- we can't have a base of 'image_node'.

Suggestions?

- picture
- picturenode
- picture_node

would do it for me since my usage scenario for "images as nodes" is Photo-Galleries and Photos added in stories and books, Photo == Picture (==image)

But being a non-native English speaker the word "picture" might not encompass the whole of this module?

Might "graphic" work? Or "visual"? These terms could work as nouns.

graphic
graphic_node
visual
visual_node

I'm thinking they'd be effective as self-explanatory words. Lastly, given the confusingly wide usage (and re-usage) of some terms within the Drupal canon (such as "context"), expanding the lexicon may help with disambiguation.

Just suggesting.

Since galleries can contain more than photos, for example screenshots, drawings, etc., I think "Picture" is too specific. However, we may have to make a compromise somewhere if we simply cannot come up with better terms. For some idea triggers, see the synonyms here: http://thesaurus.com/browse/image

We need image nodes before we can have an image_gallery module...

Yes, can some more people chime in here with either "votes" for some of the existing suggestions or add new/better ones?

Can such names be only 3 characters, so that having simply "img" is possible?
Then, instead of having things like "imagenode_node_node_view" (thats an awful lot of "nodes", which I dont think will ease code reading), that example would be "img_node_node_view".

Or: "imagepoint" / "imgpoint" , "imagespot" / "imgspot"?

It doesn't look like http://drupal.org/project/img is taken, so I'd vote to use it if you can. Fits well with img_assist too!

img_assist is poorly named and thus a bad example. The Drupal community tries to avoid abbreviations.

Also, I don't see why a D7 module should have to be a node (type). Strictly speaking, the difference is that images are used as a page. The body field has always been kinda superfluous and needless on image nodes in the past, so strictly speaking, these image pages are not content. They are entities. Entities have a page, and can have fields. The Entity API module additionally provides an access layer, so when used as dependency, the Node Access issue of image nodes is no longer an issue. Of course, all of this somewhat circles back into Media module...

If it should be an entity according to how those are used in Drupal by default, would it still be possible to enable a body text field for it (tick mark to enable on edit form, for example)?

There are many use cases where we want to describe the pictures with lots of text, so I think a body text field must be at least optional and easy to enable for the end user (per entity/node).

@Taxoman: Yes, all entities can be fieldable in D7. Thus, you can not only add a body field, but actually any kind of fields. I can only recommend to play around with core's new entity system and Entity API module a bit.

Consequentially, if a custom module resembling D6's image.module still makes sense to do, then its proper name should be image_entity.

Meanwhile, however, I doubt that this is going to be the right direction. I'd love to hear from @aaron and other Media module masters what the current status of [media-]files-as-entities is. There was some fruitful discussion at DrupalCon Chicago's Core Conversations, and overall, this idea didn't sound that hard to do... unfortunately, I've no idea in which project this is going to happen, and whether something might have happened already.

From my perspective, it simply doesn't make sense to move ahead with the identically limited design principles of good ol' Image module. Images as first class entities with pages is fine, but people very quickly want to do a lot more - EXIF and other meta-data, videos, remote media files, administrative browsing/management, inlining/embedding, galleries, importing, etc. In turn, and even though I know close to nothing about it, Media module's idea and approach sounds much more appealing than a dumb, single use-case, custom image entity module.

Yeah, Media module and the like are great concepts. And they might even solve problems like metadata and asset management. In 2015.

Apparently, Media module's latest code contains a new File Entity sub-module already. That, combined with Media itself (even providing an import facility), as well as Media Gallery module, pretty much sums up everything the Image package ever provided. Of course, differences may be found in smaller details, such as node/entity access, but those can and should be developed for Media instead then. It makes zero sense to duplicate this major effort.

Since talk is silver, and only code is gold, I'll try to fix media_gallery module to work with the latest Media code until tomorrow.

The only exception and missing piece I'm able to see is Image module's support for custom derivative image sizes, which the Image Assist module used pretty heavily. However, there never really has been any doubt that this functionality needs to be completely re-invented in light of Drupal 7's file and image handling.

And of course, we need an upgrade path from Image to Media... images are stored as files already, so the upgrade path mainly means to convert existing image nodes into file entities.

There are things that only work on nodes though -- comments for one thing.

And Taxonomy also seems to work not well with "image as field", see http://drupal.org/node/1134442

Yes, media module and its related projects seems to be the obvious way of the future for these major developments. However, the Media module seems quite complex, which makes this quite "scary", and overkill for many small sites/needs. I will not be surprised if we will be ridden with quite a few lasting bugs there even in the first stable release, until it is truly production-ready. This may turn out to take 6-12 months.

Does Aaron have a perspective as of when the Media module(s) will be "production ready"?

I fear it will prove difficult or impossible to (1) get a _reliable_ time frame for when that bunch will be in stable release(s), and (2) if that will happen soon enough to serve as an argument for not making a temporary solution with the image module...

That argument does not justify the effort by itself, though, but coupled with the following concerns it just might:

1. I think that many sites do not need the added complexity of the Media modules framework.
It would be very practical if there was an alternative for small sites with significantly less complexity.
2. I think that it is also important to have comments and taxonomy per image, as mentioned by joachim and ansorg in the comments right above here. This is actually very important.

With this in mind, I wonder if it would be possible to make the Media_gallery module support a choice:
a) use it with the Media family (using entities), OR
b) use it as a standalone module with normal nodes presented as one or more galleries. (the same photo should be possible include in more than one gallery, yet still exist as only one instance/"image node")

Edit: Typo + "credits".

This is an interesting blog post about which type of entity to use for what: http://www.agileapproach.com/blog-entry/entity-based-information-archite...

Some of the salient points:

Files:
Is it essentially used as a "supporting" file/asset (i.e. never has to be treated as "standalone" content?

Content:
Does it need to be workflow managed (i.e. worked on in an unpublished state)?
Would a user want to subscribe to its RSS feed?
Can it literally be considered as standalone "content" in a traditional sense (i.e. an article)?
Is it searchable?

The answers to those are going to be different for every site.

@joachim, thanks for the link to discussion on entities in Drupal 7 in #143. Tons of great resources there.

access control (private image for ...) voting, taxonomy and comment must be possible !
i can't use Media Gallery, because comment on image page is absent.

in Voting API: Rating of any content (comments, nodes, users, fish, whatever),
but not entity

Searchable: YES!

Security and searchability is a must, but I would be surprised if those crucial elements are not addressed in the Entities API?

Just curious, and if I missed it I apologize, but can't we get an upgrade path from 6 to 7, and then solve all the world's problems? From a user perspective, we're kind of left in the dust. All of my nodes have attached images in the teasers, and I upgraded to 7 (yeah yeah I know, but it's kind of late for the admonishments).

Anyways, my site looks pretty dull now and from what I can tell I may as well scrub what little of it that still works.

> Just curious, and if I missed it I apologize, but can't we get an upgrade path from 6 to 7, and then solve all the world's problems.

There already is an upgrade path, at least for image module (not image_attach yet).

It's a bit rough and it *needs feedback from people*, but it will take you to image nodes with an image field on them. See http://drupal.org/project/field_convert.

What we are discussing here is what functionality to provide on D7.

@sun: >Image module allows to create custom image derivative sizes for a single image (e.g., druplicon.custom-143x126.png) on-the-fly in the file system, and permanently retains those derivative sizes (also with a db-level entry), until/unless the image node is deleted. From all Image module features, this is the one I'm worried about most ... Without it, we are doomed in a world of always identical image styles/presets.
> Image module's support for custom derivative image sizes, which the Image Assist module used pretty heavily

Yep, this one's gonna be a killer for me, I've got a site that I can't upgrade to d7 because it relies to heavily on image's derivatives (used via img_assist). I'm wondering if it might be possible to create an imagefield fieldgroup or something, that applies different imagecache presets to the same parent image field? That'd more or less cover it.

Scott J's solution in #89 is potentially a gap-filler for the custom sizes, but it'd be good to have a number of presets that users can choose from (preferably with different permissions).

Actually, @sun, could the link-to-different-presets thing be done with a custom imagefield formatter that loads all available presets, and hides all but the first, and switches between then (disabling and enabling each preset as needed) with javascript (or with an additional page argument on the node when javascript is not available)?

That and a migration tool from img_assist to media module would work for me.

and what everyone expects out Drupal 9 ? :)

Subscribing

I'll be honest, I did not read all the discussion tree, it's enormous.
I'll just want say that galleries could be created also in assembly.
The problem is that in a community, let users compulsorily use view_module to make and manage galleries, it is a little bit pretentious.

I think that the way the image module let to create and mange galleries was the handy and fast and simple and accessibile way ever.
Galleries, nested sub-galleries, property, description ando so on. Just the way to display was a little insufficient,
A little module that let use galleries like image module did could rappresent a great solution.

sorry for my english

fab

I've been working with http://drupal.org/project/inline_entity_form recently, and I think it could do most of the heavy work we need for image attach. It needs:

- a patch to make nodes work with it (which I've written)
- a patch to make adding new entities inline possible (which I've reviewed, and is ready)

The missing pieces are then:

- a field formatter for entityref to show the image from the referenced image node
- allow restriction of attaching form to either just new nodes, or just existing nodes. That might be a bit more tricky, as the IEF form is rather complex and might not tolerate a form alteration like that. Could be feasible as a patch to its widget settings perhaps?

From what I have read (too hard to read everything) there is no upgrade path from image_atach to media yet. For me, this is the most obvious way to go ahead. I have no information how this compares with inline_entity_form or whether this comparison makes sense.

I'd like to point your attention to the meta issue #1665912: ChipIn for an upgrade to D7.

As you might have noticed, development of the 'image' module in general and - especially - building a complete and robust upgrade path to D7 has stalled for quite a while. D7 is mature enough to start considering major migration projects, but the incomplete upgrade path provided by modules like this one is a real showstopper for these attempts. Also it has become quite obvious, that no huge company like Acquia, and no organization like the Drupal Association will jump in and fund the migration path.

It is now time to start raising some funds to get the remaining work done; as Joachim poited out, the developers have already stopped using image module a long time ago so we need to act now, before the know-how about the module's internals vanishes and 'image' module becomes abandoned.

Unless you don't care about your images on existing sites, please read and comment on #1665912: ChipIn for an upgrade to D7!

I'll try to summarize the current status of the update path from legacy 'Image' module to the Field API based 'Image' in D7. Please read #81 and add you experiences!

  • The legacy image module consists of a content type for images and it is able to generate image derivates without an add-on module like 'Imagecache' plus four contributes sub-modules ('image_attach', 'image_gallery', 'image_im_advanced', 'image_import'), plus quite some Views integration; also there are some side aspects like access permissions, token support (is there any?) or image derivate handling that might need some attention. Some of these componenten don't require upgrade paths as they can be replaced, for some components a partial upgrade path exists, and for some components no upgrade path exists at all.
  • The image content type's upgrade path is based on the Field converter module; the current state is discussed in #757808: Image module migration, and there are a number of problems to resolve; also there is a critical core bug involved (#895014: All fields of a node type are lost on module disable).
  • For 'image_attach' there is basically no upgrade path at all and no real plan how this could work in D7. A possible approach would combine a node reference field with a new formatter for images; 'Nodereference Image Helper' is no option to hope for as the maintainers have mostly left Drupal development. There is some discussion about data migration in #1226062: Image_attach migration
  • How are existing image derivates handled? Are Imagecache presets generated? (status: unknown)
  • ImageMagick support? (status: unknown; probably something Imagecache has to care about)
  • Image Import will not be ported to D7 and will not receive an migration path; it has to be replaced by other modules from contrib (no problem here, I think).
  • 'Image' module's galleries are based on taxonomy; displaying image galleries has two parts, an older one works without Views, and the newer one requires Views; this sub-module also has some gallery handling components located at ./admin/content/image (add/edit/sort galleries). The migration of the gallery vocabulary should be handled through core, views-based galleries might be migrated through Views' upgrade path; however, I neither know how existing galleries look after a migration, nor if there are upgrade paths to other Gallery modules like Views Gallery (that might also need a port to D7).

Anything forgot?

> From what I have read (too hard to read everything) there is no upgrade path from image_atach to media yet.

I can see at several different upgrade paths:

Path A: image nodes remain as image nodes, with image files in image fields. Image attach done with entityref
Path B: image nodes becomes files, nodes with attached images become nodes with filefields / media fields.

... and there are probably more.

It's fine for there to be more than one upgrade path, as long as each one is clearly defined.

What remains in Image module for D7 however will be path A, I think. Users choosing another upgrade path will be on their own afterwards.

Node access (or a similar mechanism to create protected galleries) is an important aspect. In D6 the image nodes automatically protect the image files.

For a valid upgrade path, Title and Body need to be migrated, too.

This weighs heavily in favor of

Path A: image nodes remain as image nodes, with image files in image fields. Image attach done with entityref

> The image content type's upgrade path is based on the Field converter module

Having recently started using Migrate module for a project, I'm wondering whether it would be better to use that here. However, this is a major obstable: #1667130: allow migration classes to be hidden in the UI

So far, I've only ever heard of advanced users using Migrate. Most probably, because that has a high chance of involving PHP code that needs to be written manually. Contrary to that, I'd guess that most users being stuck on D6 are rather non-developers, who are able to use the update.php upgrade path procedure.

It would allow users to select from a range of upgrade paths. What I'm suggesting is that we ship some sort of 7.x download that contains several Migration classes. Users download and install migrate module, then pick one and run it from the UI.

I don't know if this has been outlined yet, but I think the various possible migration paths that might be needed are:

- Image module, plain image nodes:
input: nodes of type 'image' with a built-in image file
output: nodes of type 'image' with an imagefield

- Image attach, remove image nodes
input: nodes of any type with an attached image
output: same node, with the attached image converted to an imagefield
The complication here is how multiple uses of the same image should be handled

- Image attach, entityreference to image nodes
This requires 'plain image nodes' to run first.
input: nodes of any type with an attached image
output: same node, with the attached image converted to an entityreference field pointing to the image node

Further options involving filefield_sources or media module may be possible, but I don't know enough about those modules.

- Image module, plain image nodes:
input: nodes of type 'image' with a built-in image file
output: nodes of type 'image' with an imagefield

This would be a great start! :-)

Imho the approach "Image attach, remove image nodes" wouldn't be worth the effort as it opposes the whole idea behind attaching images (imge node re-use). An migration path that severely cripples existing data structures feels more like a forced "taking out the trash". Why even bother to attempt a fragmentary migration that most probably leaves the "migrated" sites with 10-90% image content broken?

Also, the possible migration paths outline is missing a crucial element as everything seems to rely on paid work: How much $ is required to get which part done?

Thanks!

> it opposes the whole idea behind attaching images (imge node re-use).

For sites that don't reuse their images and want a simple workflow. Also, there is Filefield Sources module.

> An migration path that severely cripples existing data structures feels more like a forced "taking out the trash". Why even bother to attempt a fragmentary migration that most probably leaves the "migrated" sites with 10-90% image content broken?

I'm not saying it's the one I would work on first. I'm just listing it as a possible migration path people might want. Then again, I'm not sure what people want and there is very little activity, so it's just speculation :/

As for time and cost, I was actually contacted last week by someone asking me just that, but I fear I may have put them off when I said it could be around a week of development work :(

It really depends entirely on what is needed -- are we just creating a single migration path, or do we need to replicate features of the current Image module too, and if so, which ones, and which ones first?

It doesn't seem like any single site owner or web development company is going to sponsor this work. So it's only going to happen if people pool resources together. But of course for that to happen, everyone needs to know that it's going to happen!

Perhaps rather than the chip-in widget what is needed is for people to pipe up and state that they'd be willing to contribute X amount, and we set a target at which we actually start work and ask for the promised contributions.

I do think we need about a week of dev time to make a sizable dent in this and produce something that actually works, so we could set the target at that.

We'd also need to agree on a roadmap that everyone is happy with.

But as I have previously said, I need YOU, the people who need this upgrade path, to do the legwork. You need to gather more concerned parties -- publicise it, search for sites that appear to be using Image module and contact them, and so on.

Thanks for this update, I think we understand your reasoning well (and, honestley, it seems pretty unfair to leave all the burden on your shoulders; there are other maintainers as well which appear to not even follow this issue anymore).

The 'Filefield Sources' module is a topic for itself that could be discussed at lenghths; in a nutshell, many users have tried to replicate image re-use with this thing and miserably failed. It works just on a data file, not an an image node as a whole: An image node has properties like terms, a title, description (node body) and/or CCK fields for captions; re-using an attached image keeps data integrity because the referenced target simply has all these properties. 'Filefield Sources' does not even keep the descriptions of the File Field, which is a consistency nightmare. 'Image Attach' is simply ten times as smart as 'Filefield Sources', at least from a site operators perspective - 'Image' module is KISS, Image-/Filefields are creepingly complicated.

One week, that's a concrete estimate. So we need at least something around 8 hrs x 5 days x $50/hr = ~$2,000. Yes that's clearly too much for a site owner or a small company (and it explains why so many Drupal shops recommend not to migrate to D7 but to start from scratch). To get started, I'd throw $100 in the bucket. Now we need 19 more sponsors with equal shares to get started, and maybe another 5 for some beauty and usability. Reported installs as of today: "77,761 sites currently report using this module".

Heads-up: Mike Ryan's Migrate Drupal to Drupal includes an example module that includes an image migration. If you set up an "Image" node type, with a "Main image" image field (field_main_image), then replace the source path in the code, and set up the DB settings for the migration, it should work close to out-of-the-box. That gets you your images-as-nodes.

The difficulty then is migrating img_assist filter tags to media.module tags or something. But it should be doable by copying the img_assist tag parsing code, and using the media.module's encoder.

That's good news!

I was going to say also that last night I re-read the Migrate docs and rediscovered the System of Record settings, which I'd forgotten existed.

Both that and the code in D2D will shave off quite a bit of development time :)

> The difficulty then is migrating img_assist filter tags to media.module tags or something.

Agh, I've not even considered img_assist yet!

Actually, it doesn't look like the Migrate D2D example class has much to do with Image module:

    $image_row = Database::getConnection('default', $this->sourceConnection)
                 ->select('custom_image_table', 'i')
                 ->fields('i', array('copyright', 'filename'))
                 ->condition('vid', $row->vid)
                 ->execute()
                 ->fetchObject();

That isn't our table name, and those are not our fields!

No, that's right, it's not assuming that you're using a particular image module (could be using image fields). But you can replace it with something like this (I'm trying to upgrade some d5 sites, so this is a bit wrong for d6 - 'files' should be 'images' or something, I forget)

$image_row = Database::getConnection('default', $this->sourceConnection)
                 ->select('files', 'i')
                 ->fields('i', array('filepath'))
                 ->condition('nid', $row->nid)
                 ->condition('filename', '_original')
                 ->execute()
                 ->fetchObject();

It definitely works.

Also, that code is for upgrading a whole site that's in another database, whereas what I am after here is this workflow:

1. Run the regular core D6-D7 upgrade
2. Run the Image Upgrade migration

So the {image} table would be in the local database, not a foreign one.

It's a good starting point though, but not really OOTB functionality :)

Since last year, almost 30,000 users of image.module successfully have been scared of (current count of installations: 49,964; february 2013 count: "77,761 sites currently report using this module").

At this rate, we just have to sit through another two years and this issue will have solved itself. Statistically at least ;)