New HB: Image-handling overview and comparison

Hans, Thank you for your efforts on this.

I can't help a great deal as I have not used this area of Drupal much yet, but believe that a big *performance* issue relates to whether you have file access configured as private or public.

As I understand it (could be quite wrong) public files are referenced by direct links to the files, which can be served by the web server swiftly, whereas private ones have the word "system" in the path somewhere. The word "system" is picked up by either .htaccess or a Drupal 'handler' (?) causing Drupal to be 'bootstrapped' to check whether access is allowed. This is much more processing than just Apache (or if you are unfortunate ;) IIS, or ???) serving the file.

I did find an article once containing a method of running private *and* public files, which seems like a good idea for some site requirements, but I think this is unusual. From memory it used .htaccess files to add the word "system" in the relevant place for selected files, forcing them to be private.

Someone with a better understanding could probably clarify this, but it's a start to explaining a 'high level' performance option.

Hi Hans,

I think that public/private is the point. AFAIK, you cannot control access to the files with Drupal unless you select 'private'. If public, Drupal does not restrict access to the files at all.

For handbook content, rather than potentially confuse people, I would be happier if someone who knows definitively how this works would cut/paste and edit my text into the performance section.

I'm working hard on Drupal, but have only been doing so for a few months and attention has been split over many areas, so I currently feel I'm a 'Jack of all trades' that can get things done 'somehow' rather than an authoritative technical document writer :) ... but I will chip in where I can.

D

Hi Hans,

OK, perhaps it wasn't clear. I meant: 'My point' is specifically about private/public file system setting when used with images, and how that impacts perceived performance (more specifically, page load times).

As I emphasised in my first comment, I was suggesting some content that could go into the *performance* section that you have created as a stub in the handbook. That was because I have researched this aspect.

I do not have experience in the more general area of using images in Drupal, so I only tried to help in *the performance area* - That's all.

I thought you wanted contributions in this thread that could be added to the handbook, rather than comments on the pages, so that's what I tried to do.

If as you say "performance issues and file access restrictions are IMO pretty tangential to that topic", I'm not quite sure what the performance section is for, so feel free to ignore my attempt to contribute.

Also, I didn't take in that this was exclusively for newbies. "The purpose of my work here is to give newbies an overview ... ". I thought it was going to be more generally useful as a comparison of methods and modules.

Thinking about it ... I'm not sure if the handbook in general is meant exclusively for newbies or for use as a reference. I'll take another look. I'm still on the Drupal learning curve myself.

Your multi-site/sub-site suggestion is interesting and could be very useful. Thank you for thinking out loud.

Cheers, Dru-p

This is some great documentation! Thanks for starting this project. One note I would suggest would be to write in the third person rather than first person. Also, some of the warnings ("Don't edit here, post to issue first") are intimidating. Might be better to simply ask for editors to note their changes in the issue. The point of revisions is that we have a history of things, and I suggest we keep to the spirit of wiki documentation here.

OK, one often-overlooked helper module for http://drupal.org/project/image is http://drupal.org/project/image_filter .

It's a nice alternative to image's included image_attach module:
1) it doesn't need its own table
2) you can add any size image (within reason) to your nodes
3) you can add any number of images to your nodes

Drawbacks:
-1) you need to know the node number of any given image, which means that only admins can use it. If that's OK, then it beats image_attach hands-down.

(Also, it's http://drupal.org/project/img_assist , not image_assist ...)

img_assist: I tried it out a year or so ago, when I decided on my site setup, but it didn't fit my needs - ah yes, it requires too many other modules (token, views, etc.), and my site is under heavy enough pressure as is (it eats 20-25 % of shared server CPU ...). If drupal's cache modules get better that's no longer a problem, but as is, it's a no-go.

image_filter lets you reuse existing image nodes, provided you know the node number.

image_attach lets you reuse existing image nodes, and lets you search by image name, but only lets you add one image per book/blog/whatnot node. There's a few attempts to address this in the image queue, but nothing that'd get included in the official version.

Sorry, I think you called it image_assist somewhere or other (where you compared it with image_attach), but you didn't give a link in that post.

Concerning http://drupal.org/node/316884

I think this page is in need of a re-write. But I'm wary of making changes directly, as they would be quite extensive. So I'm putting my suggestion here.

Quote from the page:

There are hundreds of threads on drupal.org illustrating the complexity and confusion the new Drupal user experiences in trying to make an informed decision on what image-handling modules to choose to fit the needs of a given site. 1 2 3 4 5 6 7 8 9 10 11 12

I think your first sentence here is stating the obvious for users- and possibly making the task more daunting, where you want to be giving them guidance and making the task less daunting. I can't tell what a list of 12 links offers as help to a user. The numbers are arbitrary, and the reader is lead to wonder... what is that link? Mystery links aren't attractive in this context. Perhaps if you want to list to the forum topics, then include their titles? Even then, they have come to the handbook, and possibly sifted through alot of back-and-forth on forums. I would remove the list of links.

The best page you link to is an external page, but the link, again, is a mystery link. Change:
" Here is an external page created to encourage discussion of this topic." to:
To find out more, read David Newkerk's "Roundup of image modules for Drupal" retrieved: 30 August 08

In the third sentence you seem to be criticizing Drupal core (that" there is very little to even support various contributed modules, other than basic file handling routines")... so I'm not sure what this offers to the new user who is looking for guidance on how to handle images in Drupal. For the new user it is a distraction and non-essential information to the task. It is also a negative tone and might be demoralizing.

This page (and section) should answer the following questions:

• How could I handle images in Drupal?
• What options are available to me?
• What are the considerations so I can make the best decision?

Regarding the security of input filter for WYWIWYG rich text editors at http://drupal.org/node/325296, perhaps HTML Purifier should be used instead of "Full HTML" or "Filtered HTML" with img element added.

@Hans: SO happy to have found your work here! What a hugely valuable and important contribution you're making!

Some feedback from the perspective of someone solidly in your target audience (I'm very much needing to get my head around the various options, approaches and issues):

(1.) Image Reusability
This page seemed like it might need some work. (Or, of course, I was missing the point).

Nearly all the various image-handling modules allow you to display a given image in multiple nodes by treating an image as an asset.

Other image handling modules allow you to upload images into a node, but these images are only linked from the node itself. To get this image to display in another node, you'd either have to re-upload that image, or identifty the location of the image, and paste in the link as an img src tag using standard HTML <img /> tags.

Inline and Imagefield are two contributed modules which work in this way.

This was confusing to me. The "Nearly all [modules]..." then "Other [modules]..." phrasing threw me off. Are you saying that "nearly all" image-handling modules provide natively for 1-to-many relationships between images and nodes, while "other" (i.e., "some") do not (though that limitation can be worked around)?

I would suggest something along the lines of

Nearly all the various image-handling modules allow you to display a given image in multiple nodes by treating an image as an asset. However, some image-handling modules, such as Inline and Imagefield, do not.

Also, the material seems to sort of slide right from the general discussion into a consideration of work-arounds for Imagefield, which was confusing to me - are we talking about Image Reusablity per se, about the distinction between modules that do and do not provide for reusability, or Imagefield?

(But then, this leaves me wondering, what is the purpose of this page? Isn't this covered in file-to-node relationships? Perhaps I'm missing something??)

(2.) Ease of use
I think the comparison (first paragraph) between insertion processes that on the one hand are "transparent to the user" and, on the other hand, those that require "hand-typing macro tags with cryptic syntax" comes off as a criticism of the latter. I know your intention here is to stay value-neutral, so maybe some other phrasing would be a better fit. Maybe, "some modules strive for high ease of use with a point-and-click-style interface, while others require a certain amount of technical know-how."

Anyway... Again, many kudos and thanks! I can imagine how hard this task must be!

subscribing

Hans, it's fantastic to see these efforts to describe the current image/media handling hullabaloo in Drupal. I am going to spend some time editing and adding to the pages you've posted already (in the spirit of the handbook authoring guidelines). I'll post back here with notification of my major edits and see if there are improvements we can continue to make.

img_assist: I tried it out a year or so ago, when I decided on my site setup, but it didn't fit my needs - ah yes, it requires too many other modules (token, views, etc.), and my site is under heavy enough pressure as is (it eats 20-25 % of shared server CPU ...). If drupal's cache modules get better that's no longer a problem, but as is, it's a no-go.

Minor clarification: AFAIK img_assist module is dependent only on the image module. Not sure why you think it needs token & views support. It never has, to my knowledge.

This seems more or less done. Definitely hasn't been worked on in a while so I'm going to mark as fixed.

FYI - new stub pages have been created in the handbook for field and field UI (now used for image field) http://drupal.org/handbook/modules/field and http://drupal.org/handbook/modules/field-ui, as well as file http://drupal.org/handbook/modules/file

this will probably need to be reflected in the above docs.

(unassigning from hans, since he hasn't commented in over a year on here)

Hello Arianek,

I see the new stub pages for the file field & associated UI, but this doesn't answer the overall questions about "Image handling best practices" which alot of people have questions about.

Since these pages were drafted in '08 things have moved on quite a bit in the world of image handling(!)

I recently started writing up a document advising about Image handling best practices... and I'd like to post it on D.O for reference and also community input... But all the pages associated with this best practice topic point to this withering thread.
The pages: http://drupal.org/node/316884

Could we scrap the bulk of the structure in the first attempt? It seems to have many many stub pages. I'm in favour of starting small and growing organically, on an as-needed basis.

I recommended a user-goal focused approach, with only 3 sections.

How could I handle images in Drupal? (explain at a high level the different approaches)
What options are available to me? (listing modules, clustered with associated modules which extend functionality)
What are the considerations so I can make the best decision? (Q + A, what to consider for you own situation, and point to which solution is best)

I'll hang out in IRC over the next week and see if I can jump in and get this off the ground

on IRC my ID is "nearlythere"!

I wanted to note that we have two image handling sections in different places with an unfortunate amount of overlap. There's the comparison of image handling modules section (http://drupal.org/node/316884) which has been the focus of this thread and then there's this section which on working with media and files (http://drupal.org/node/627244).

The user-goal focused approach you mention is really desperately needed but it should probably go in the section on working with media and files (http://drupal.org/node/627244).

I actually think that the various module comparisons should be moved to the relevant areas - eg the image handling module comparison should be added to the bottom of the image handling section of the documentation as a reference - but I got some flak when I tried doing this before.

Right now there's nearly enough content just on image and media handling for a small book but there's also, as I mentioned, quite a lot of duplication and a really bewildering number of modules.

Lee's been working on sorting out the structure and organization for the handbook, so I'll give my vote of support on his input.

But yes, the functionality for images in D7 has changed a lot, so that should definitely be incorporated and appropriately linked to (or even partly written in the field module handbook page in particular).

Heya Lee & Arianek,

To make a vital improvement then, I propose:

1) You (someone with rights) could archive those "stub" page then?

It's not only misleading, but looks poorly on the community- is it's a job undone.

2) I say we remove references to this thread, close it. This thread was only relating to that other approach, and I think it's been discussed and abandoned at this stage.

3) Redirect those stub pages to

http://drupal.org/node/627244 - Media & Files or,
http://drupal.org/node/627244 - Image handling

I have had clients locate those stub pages and they seem to bump up in SERPs and Drupal's on site search.

Is that change agreeable to you both?

I then say we pick up the discussion in a new thread: new-user overview of image handling approaches in Drupal 6 and 7.

Here is the thread: #702238: High level overview of image handling options for new users of d6 and d7

Can we redirect those stub pages and close this puppy?

- Heather

Just an update...

I am abandoning the idea of putting these pages in the Media section, so you can ignore all of my comments and suggestions above!

I had thought I was suggesting a sufficiently different direction than this thread (as well as trying to close this thread). Arianek suggested closing the other thread, so I marked it duplicate.

So... I'm going to develop this content off site, and later, if needed/wanted it could be integrated.

Thanks all for the feedback,

- Heather

ok, well let's definitely leave this open, someone else may take it on - if someone does, please also see the notes on #702238: High level overview of image handling options for new users of d6 and d7

Those pages have since been fleshed out into proper docs pages. Closing this.