so i'm trying to get a discussion going here regarding the apparent fork i see with image management solutions. on one hand, and this all relates to DRUPAL 6 ONLY ! - there is the popular imagecache with imagefield and what i would broadly describe as the "CCK approach" and then there is the more traditional "image module approach" (replete with one-click galleries and all of that)

so again, what i see is a slew of modules supporting or tying to either:
1) cck approach (image as node attribute/field/element etc)
2) image module approach (image as node/content type)

both benefit from cache and resize options and so on, but only option 2 presents a group of folks working toward, for example, an inline api for inline image management and so on (a great approach)...

MAJOR drawbacks to both approaches:
*limited control of image placement and inline management "as part of the module" (excluding some test stage stuff for approach 2)
*excessive dependency on myriad 'other' modules to get stuff done
*no clear statement from the drupal core guys regarding a future for this subject (images) - even acquia has 'both approaches' stuffed into carbon
*some other stuff (discussed below)

is it just me, or is the ability to control not only the size (solved already) but also the *placement* of images paramount to drupal users? not all articles (for example) should just drop photos up top or below, nor should articles (using image for example) rely upon nodes within nodes and so on..

BOTH approaches get a bit nerdy for new drupalers - particularly imagecache and imagefield, as those push a user toward cck and a whole bunch of stuff he or she may not be thinking about at all...and then of course image module when users realize that putting up more than one image into a node/story gets difficult or testy...

...so, my **personal opinion** is that the CCK field approach is a much more elegant and flexible approach to image management within a drupal installation and gives users tremendous control over how and when images appear (with fine grained 'views use' potential by exposing elements to views)...but it's nerdy and complicated for new users (multiple modules, and nothing is "super crystal clear" - like, "i've got filefield in there, but do i need mime modules thing too, and oh, i forgot this other cache thing, on and then this api module, oh and now there are like four other modules in the admin screen under this module, what do they do?"

any thoughts on this? any thinking about common issues, like handling image placement in a current d6 install, or dealing with "consolidation of requirements for using pictures on a drupal site" with a great big "this or that" explanation and a very clear list of things that must be done and downloaded to make it all work...

i've been using drupal for years though i'm new to image management issues - i was actually using img_filter on a d6 site but it's been abandoned! (it was great)...usually i can figure out everything once i investigate the workflow or the nature of the task in detail, but i can only imagine what's going through the minds of a million people pulling down d6 for the first time wondering why it's so hard to work with images...

Comments

zilla’s picture

from this month:
http://brianpuccio.net/image_field_and_image_to_merge_by_drupal_7

think this is going to happen? will it for d6? could acquia do it for carbon?

..and this recent discussion, in which an AWESOME idea got dinged as a summer of code project (fascinating, confounding too)
http://groups.drupal.org/node/9957#comment-32471

........................................................................
i love to waste time: http://twitter.com/passingnotes