Images in Drupal - Future-proof methodology (Image module + imagefield together)

We encourage users to post events happening in the community to the community events group on https://www.drupal.org.
HansBKK's picture

I am prototyping my first Drupal site using 5.10, and have spent 40+ hours researching the many ways of posting images - or at least the top dozen mainstream methods (yes fellow noobs everyone feels your pain on this!)

I want to have a single standard workflow for uploading/attaching/displaying all images on the site, so that I have both maximum flexibility now and protection against the coming changes in how Drupal (core?) will handle them - I don't want to have to do complex data conversions later on, or God forbid manual editing of old nodes.

My proposals and questions will reflect my status as a relative newbie, so please do correct any misunderstandings they may reveal and let me know if I'm way off-base on anything; I understand that these ideas may be overkill, but my main question (Q1) is - will it work, i.e. are there any technical incompatibilities?

  1. Set up CCK/Imagefield/Imagecache, define my presets (e.g. tiny, thumb, preview, fullsize, max)

  2. Set up Image module, and Upload Image, maybe Image Assist or Inline

  3. Create a CCK-based node type (e.g. Article) containing two Imagefields (e.g. image-1 and image-mult). Store the "primary" image for the node (the one that will show in a teaser listing) in image-1 and the rest in image-mult. These will most likely be the images I will base my display design around, using imagecache's derivatives appropriately, and if at all possible I'll base ALL display of these images around these methods for consistency and efficiency.

  4. For the SAME Article node, use Upload Image to "attach" ALL of the SAME files. This will then automagically create Image type nodes for each image file, linking them to the "parent" Article node by (I believe) BOTH the method used by Upload module and that used by Image Assist.

This linkage will then be a just-in-case, fallback way of structuring displays if I want to use modules based on Image module's methods rather than Imagefield's.

And these (children) Image nodes will then also be independently available for tagging with taxonomy, linking from or attaching to other nodes, creating galleries, rating/voting etc. if desired in the future.

AND the files will be addressable as files in the filesystem independently of anything stored in the database.

Ideally step 4 can be made to upload the SAME files to the SAME locations in the filesystem as step 3, preventing wastage of disk space. (Q2)

Subsidiary questions:

(Q3) Inline or Asset module for displaying imagecache's derivative images within the node's content body? Or just regular linking to the image files directly from the filesystem, perhaps assisted by FCKedit or TinyMCE?

(Q4) I believe Views will actually let me pick up either/both the Imageassist-linked node images and the Imagefield-embedded ones?

(Q5) I'd like to use Lightbox - any suggestions for compatibility there?

Thanks in advance to any who take the time to respond; once I've organized my notes I'll post a summary here to save others some time.

Comments

Image Module vs. ImageField Module

Brian@brianpuccio.net's picture

I don't pretend to the be the voice of authority on this issue, but I'll throw in my two cents...

As per the ImageField project page, it is incompatible with Image Module:

Imagefield is not compatible with image.module content types. If you add an imagefield CCK field to the image type provided by image module, image module will delete all the imagefield images on every node update.

So right away, it looks like you can't use both. Though maybe doing what you're doing, you can.

Second, I was at Drupal Camp NYC this past weekend and one thing that I took away was that ImageField and Image were going to merge.

Third, there's already a migration script to go from Image module to ImageField module.

All of these things indicate to me that it doesn't matter what you use now because they will merge, though you do at this time have the option to migration from Image module to ImageField module, if you should so choose.

Thanks Brian, spot on

HansBKK's picture

These issues are exactly why I've formulated these ideas!

BTW MAQUM looks way cool, I'll definitely be checking that out (assuming I don't end up going with imagefield-only images). What do you recommend for Win-based photo storage/cataloging, if price weren't an issue?

Regarding the incompatibility you point out, AFAICT this is only an issue on a per-node basis, not system-wide. The workflow I outlined should create one node of CCK type Article (the "parent") for the Imagefield data, and the intention is that Image module won't be touching this node at all.

All the Image-type nodes (non CCK) get created separately by Upload Image. That module also is supposed to create the links between the parent and the new children nodes the same way Image Assist does (AFAIK - Q6?), as well as also creating Upload module style file attachment links to the files actual location in the filesystem.

My belief and intention is that this separation will avoid any problem with this incompatibility issue.

Regarding the "future direction of images in Drupal" discussion, this is exactly what I meant by "protection against the coming changes in how Drupal (core?) will handle them". Of course future conversion scripts should in theory handle this, but as I'm not a PHP guy I hate to depend on scripts I won't understand or be able to fix if they don't work.

More importantly however is the fact that I don't even currently know exactly how I want to work with/display the images over other areas of the site, and in fact I'm sure my site's design and architecture will be radically evolving even within the current core version cycle.

For example, I know I want to both display my images inline with the content in full node display, and imagefield apparently doesn't allow for this?

But I also want to have imagecache-derived thumbnails displayed in teaser views, maybe different sizes in different views. And I'm sure I'll change my mind on how large I want the graphics to display in my Views later on. Image module seems to only allow a fixed set of presets that can't be varied per node or by node type, while imagecache gives more flexibility, especially with Views.

And I'll want to re-use these images in other locations within the site, and this seems difficult with imagefield. Down the road I'll probably want to put in taxonomy-based galleries, which requires image-as-nodes. I know it's possible to just have a single node per image with imagefield and create my own View-based galleries, but some gallery implementations (and the easier ones?) use Image module's infrastructure.

And so on. This is why I'm hoping my method will allow me to invest a little more overhead up front, with two main payoffs; 1 complete flexibility in how I can work with my images, and 2 I won't have to touch these nodes in the future.

If no one here's tried this before I'll be the pioneer and report back on the arrows :)

Some authoritative information

HansBKK's picture

From dopry via email:

It's safe to use both... Just don't use imagefields on image nodes. The disassociation can be a little confusing for those looking for a one size fits all... but reusable images in image.module and node specific images in imagefield is a workable solution for 5.x.

I then asked about in-line placement of an image stored in an Imagefield along the lines of Image Assist, or Inline module's substitution tags; dopry replied:

theoretically the same inline tags should work for imagefield as long as it references fid. I haven't tested this in a long time. The module which provides the inline image tags could be modified to specify a filefield and file delta as well.

More authoritative info

HansBKK's picture

These between me (single >) and sun (double >>)

I'm assuming Views will be the way to go, and I haven't started looking at that yet, but it seems Views is compatible with nearly all the mainstream methods, except possibly those linking directly from content to the filesystem.

Yes. I'd recommend CCK content-types, all implementing (re-using) the same ImageField, because your description sounds like the layout/design of posts on your site should always look the same, independently of the content-type and image placement.

My note - If choosing one or the other, Image will also allow the above (Views-based standard teaser/list displays) for those images I want to re-use elsewhere on the site, while Imagefield is more efficient for images specific to just that node. In my proposed methodology above, I'd have both available anyway.

Do you see any compatibility issues in reduntantly storing images using core Upload, Image module (whether via Attach or Assist) as well as Imagefield (as long as I'm not adding filefields to Image's non-CCK nodes)? What about adding Asset and/or IMCE into the mix?

There will be no conflict in terms of those modules and their data. However, Image/Image Attach/Image Assist/ImageField follow the concept of files managed by the CMS. Asset and IMCE are just using the filesystem and do not store any information about images/files in the database, AFAIK.

Unfortunately, none of Inline/IA/IMCE/Asset provide an integration with fields in content-types (f.e. ImageField) yet. So for embedding and placing images at arbitrary positions in a content's body, you either have to use Upload (for Inline) or Image (for Image Assist), or use an unmanaged approach like Asset or IMCE. Hence I wrote the battle-plan on content-editing in Drupal.

My note - see http://groups.drupal.org/node/8707 and http://groups.drupal.org/wysiwyg

I'm starting to get a handle on how (some of my more technical) users will be able to insert images inline with their posts' content, and assume between IA and Inline that'll be covered.

Admittedly, Inline is not very user-friendly; Image Assist is better for novice users that do not like to type cryptic tags. Both use macros ([inline] or [img_assist]) which expand to a rendered image and give the user good control over placement inline with their post.

Other than img tags linking directly to the filesystem, are there any other inline options?

Personally, I would not recommend any unmanaged solution that inserts hard-coded IMG tags into contents, because this approach is not future-proof. IMCE works in Wysiwyg Editor editor only. I cannot speak for Asset.

My note - Thanks Daniel!

As a quick clarification:

wmostrey's picture

As a quick clarification: asset nicely stores information about the uploaded files in the {files} table. It also stores extra asset-specific information in the {asset} table.

Started to have a look at Asset - good stuff!

HansBKK's picture

http://drupal.org/node/302257#comment-1042880

http://drupal.org/node/316974

Sorry for the repetition, which is why I'm not repeating again here.

Some questions for Wim if he's around ( I know there are better places but I'm feeling lazy at the moment and plan to post all relevant details with step-by-step cookbooks for newbies on my "Futureproof" methodology, hopefully as handbook pages)

Q1 If I end up wanting to re-locate my Asset-uploaded files using WebFM, will that cause problems for Asset?

Q2 So far I've seen most file-related modules just referencing the file table's row via the fid field, so the only location of the file's path is there - to my mind that would be the definition of a well-behaved file-related module - feedback?

Q3 Is there any way to have Asset to stop showing the user-based directory under files as the starting default point? I'm the only one contributing content to the site so far. Ideally I'd like to see token-based handling like Upload Path and Pathauto (NOT like Imagefield's - the date-based ones there are broken big-time)

Started Handbook pages

HansBKK's picture

I'm still not completely set on my own choices yet, but as I've been doing my research over the past few weeks I feel I've learned a lot and I've been taking decent notes, so I figure it's time to give back a bit.

I'm starting to put together an "Overview of Image-handling in Drupal" targeted at fellow noobies, not just giving my opinions but helping them figure out how to choose their modules based on their needs.

Feedback on the initial couple of pages and more importantly ideas about structuring the section would be most welcome.

http://drupal.org/node/325323

Image

Group organizers

Group notifications

This group offers an RSS feed. Or subscribe to these personalized, sitewide feeds: