sorry to add another post about the legendary image issue, but i'm going to ask a few specific questions about the best way for integrating images into other content.

project requirements (very common, i believe):

  • rich-text editing for adding content
  • ability to insert images into content via a graphical interface
  • ability to insert images in a non-templated way (e.g. size and placement may vary between nodes)
  • ability to reuse images in multiple nodes
  • whether images are nodes or not is relatively unimportant
  • forward compatibility!

i've listened to the Lullabot "deprecated" podcast, and read their "Image and Image Exact Sizes vs. Imagefield and ImageCache" article. i know that lots of folks are recommending moving away from the Image module in favor of a CCK-based approach. but it seems to me that there are some things that the alternative CCK + Imagefield solution can't handle.

1) arbitrary placement -- with a CCK-based approach you'd need to theme your images in a standard way, e.g. for all nodes of a particular content type

2) wysiwyg/rich-text integration -- not possible to achieve w/ CCK and Imagefield, right?

3) private files -- a bit of a tangent, but files must be public to use ImageCache, and that seems like a non-starter for any site that needs privileged content (e.g. certain files only available to certain user roles)

in general, a CCK based approach seems fitting in situations like the Lullabot article above where you have a specific set of images needed for a given content type, that can be themed in one templated way. but it doesn't seem to be workable for a more open-ended situation where authors need the freedom to add images in various different ways. am i missing anything there?

so, it seems that for a set of requirements like those i've sketched out above, we're left with either:

A) Image + Image Assist

B) IMCE (if using TinyMCE for the rich-text editing)

and the choice between these two will come down to whether you want your images to be nodes, and ease-of-use.

finally, where does that leave us in terms of forward-compatibility? if Image is indeed deprecated, and some CCK-based approach is developed in the future that better handles the type of requirements i've sketched out here, how painful will it be to migrate our content?

any feedback is appreciated.

-- andy

Comments

xmacinfo’s picture

There is no perfect image module that will do everything in Drupal.

However, there are a lot of perfect image modules for specific tasks. You need to try them and choose the ones that best fit your requirements.

On some site I install only IMCE. On others I install Acidfree/Image. And still on others I install Image assist in addition.

I have not tried CCK-based images fields yet nor ImageCache, but I'm sure that under certains circumtances, they would be a better choice.

joep.hendrix’s picture

Interesting questions...

-----------------------------------------
Joep
CompuBase, Dutch Drupal full service agency

arh1’s picture

i think my original post was too long to elicit much response ;) , but based on my own research here are a few scenarios i've lined up for what i consider common project requirements...

1) CCK + Imagefield -- if you have a specific set of images needed for each node of a given content type, like the Lullabot article linked above

2) IMCE (this is what i'll use, with TinyMCE, for the project from my original post above) -- if you don't want images as nodes, and just need a browser-based UI for adding arbitrary images to node content

3) Image + Image Assist -- if you do want images as nodes and need a browser-based UI for adding arbitrary image nodes to the content of other nodes

gav240z’s picture

Don't worry I'm just as confused here and would like to answer too.

I have removed the image module from my site and am now using CCK + Views for an image gallery: See here http://www.vintagejdm.com/gallery

Great, I can see the advantages, but when it comes to blog posts and attaching images here, what is the best solution?

ideally TinyMCE with the image button for sake of ease of use for my members.

I've briefly looked at IMCE, but not sure how it works. Do you use file attachments?

Frankly there are too many image modules and nothing specifically easy when it comes to Drupal.

Hopefully someone with more experience can chime in.

arh1’s picture

@gav240z -- i wouldn't say "confused", as much as this is an admitted/notorious weakness of Drupal (depending on who you ask ;) ). the weakness being simple, unified (core?) handling of supporting media like images. (see the "legendary" link in my original post above.)

option 2 from my previous comment (TinyMCE + IMCE) is what i use most of the time now, though i could see option 1 making a lot of sense for certain situations. personally, i don't ever need images to be their own nodes, so i don't use option 3.

IMCE is basically a file browser window that sits on top of Drupal -- it lets you upload, browse/select, and delete files on your Drupal site. i like it b/c it's lightweight and doesn't muck with the database at all. if it went away tomorrow my data will still work fine, and i could manually upload images and add the appropriate markup to my content. it integrates with TinyMCE's image button out of the box (the interface is a bit cumbersome, but it works).

you've got a nice looking site! good luck...

gav240z’s picture

Thanks for the compliments on the website. I'm still wrestling with Drupal's theme system to get it to layout the way I want it to. I'll get there though, its just a slow learning process.

I listened to the entire Lullabot Pod Cast regarding deprecated methods, which I wish I had heard earlier since it would have saved me alot of time with different modules, but alas all part of the learning experience.

I have IMCE at the moment, but haven't played with it much. Seems useful for my users though.

Can you use ImageCache with it? To resize to desired sizes and then provide a large version once clicked on?

One other problem with IMCE is that it uses the body styling of my theme, which unfortunately isn't a white bg. I'll take a peek at the IMCE modules CSS and see if I can overwrite it or something. Bit difficult to explain but because I use an image for a background on my website that comes through in the IMCE window - bit annoying and not very professional looking.

ImageField seems to limit the amount of images you can upload to a node to 1. Is this true? Or can I upload multiple images? I think I may have missed an option somewhere.

I just followed a tutorial on CCK / Views Image Gallery to get me familiar with both Views and CCK. I'm still a newbie with this stuff.

I'm glad I scraped the image module, it came with so many modules that just made it confusing. ImageField and ImageCache seem like a much more elegant - albeit it slightly complex solution.

plan9’s picture

I realize this is an old post: but here are my current observations...

While cck and imagefield provide flexibility beyond image module - Image can automatically provide nodes for each uploaded images. This is a huge benefit. For example: you can have a comment form beneath images. You can also tag images for searches.

With imagefield it's difficult to reference individual images in views. You can show all images, first image or last image. But you can't target specific images - or add taxonomy tags to an image.

pkej’s picture

The thing is that when using imagefield I often end up creating a node type called image, just to get the benefits of using for example comments, creative commons licenses etc.

However, one thing which makes me use imagefield now, is the epsacrop module, the only good implementation I've tried out. I've had problems with other solutions, both for image and imagefield, sometimes UI related, sometimes missing imagecache integration (image) etc.

There also is a way for imagefields to reference images on another domain, which I find very nice, as well as referencing existing image files in the system.

And IIRC the Exif module works well with imagfields and tokens.

These, and in addition token support for paths and similar makes filefield and imagefield very versatile.

Paul K Egell-Johnsen