Image handling in Drupal needs to be better integrated and the functionality improved so that:

* entry level users can upload images and included them as inline content (e.g. in blogs, articles, pages and possibly blocks)
* no HTML coding should be required
* uploaded images should be available for inclusion in Galleries
* the functionality should be available either by just installing the image module, or preferably, as part of the core for Drupal 7- nearly every website using Drupal would have cause to show some images, and many would show a lot.
* the image handling should be easily invoked via a standard interface/API so that rich text editors can access it.
* technical settings and clutter should be avoided in simple dialogue boxes, but accessible via an "Advanced settings" button on the dialogue box
* special tags should be avoided in content that is visible to users, or at the preview function should render the images included using them.
* input filters should be enabled to display any special tags rather then this having to be located and set manually,
* dialogue boxes and functionality needs to be browser independent.

Comments

Status:Active» Postponed (maintainer needs more info)

1a) upload images: image_import or image_attach do that
1b) include as inline content: image_filter does that

2) image_filter does that

3) images/contrib/image_galleries does that, when you upload the image to drupal.
If you didn't attach an image to a gallery when you uploaded it, you can edit your node, and select the gallery from the drop-down menu of image galleries.

4) installing: you'll need image_filter as well, if you want to avoid html code. image/contrib/image_attach works nicely, too, out of the box, if you only want one image per node, and that at the same spot for every node you use it with.

5) how do you propose this should work? Cos the rich text editors I've seen, for drupal, SUCK.

6) please roll a patch. I'll review it, if it's for a version of Image which I currently use.

7) what special tags in image are currently bothering you? And sorry, I don't understand the sentence "or at the preview function should render the images included using them.".

8) dunno, should you roll a patch against image or drupal core's input filter? Or taxonomy?

9) which dialogues and functionalities are currently not browser independent?

Thanks.

Thanks for your prompt response. The original requirements numbered are:

1. entry level users can upload images and included them as inline content (e.g. in blogs, articles, pages and possibly blocks)
2. no HTML coding should be required
3. uploaded images should be available for inclusion in Galleries
4. the functionality should be available either by just installing the image module, or preferably, as part of the core for Drupal 7- nearly every website using Drupal would have cause to show some images, and many would show a lot.
5. the image handling should be easily invoked via a standard interface/API so that rich text editors can access it.
6. technical settings and clutter should be avoided in simple dialogue boxes, but accessible via an "Advanced settings" button on the dialogue box
7. special tags should be avoided in content that is visible to users, or at the preview function should render the images included using them.
8. input filters should be enabled to display any special tags rather then this having to be located and set manually,
9. dialogue boxes and functionality needs to be browser independent.

Additional requirements:

10. Multiple images per article with flexible positioning - left, center, right
11. %sizing adjustment via single field (eg: 50% to halve image size)
12. Thumbnail option (like MediaWiki image tag)

1a) upload images: image_import or image_attach do that
> Yes, agreed

1b) include as inline content: image_filter does that
> Yes, but you need to find and edit the input format to enable this tag - something newbies would really struggle with - the tag should be enabled by default for filtered HTML

2) image_filter does that
> But you still need to know how to specify a tag, which newbies would have to learn. I haven't found mention of image_filter until you suggested it, after some extensive searching. You also reference an image by its node ID, rather than its "title", which is something newbies would also really struggle with.

3) images/contrib/image_galleries does that, when you upload the image to drupal.
If you didn't attach an image to a gallery when you uploaded it, you can edit your node, and select the gallery from the drop-down menu of image galleries.

> Yes. However, I think there should be default gallery for all images without a user selected gallery. Or a view you can filter to show "images without a gallery"

4) installing: you'll need image_filter as well, if you want to avoid html code. image/contrib/image_attach works nicely, too, out of the box, if you only want one image per node, and that at the same spot for every node you use it with.
> One image per node with no control on how it displays in the body text (thumbnail only) is not really very useful. Many typical article and blog postings would display a number of images throughout them, with text wrapping left, right or above/below.

5) how do you propose this should work? Cos the rich text editors I've seen, for drupal, SUCK.
>I suggest a dialogue box (similar to that presented by Image Assist) is required to browse and add images to inline content with the option of uploading. However, Image Assist uploads just put up the image, they don't create an image node, hence the images cannot be included in galleries, or listed via http://site/admin/content/node. Whether or not RTEs suck, they should able to invoke a standard Drupal image handling dialogue box (and functions accessible by it).

6) please roll a patch. I'll review it, if it's for a version of Image which I currently use.
>Sorry, I don't know how to do this. I work in IT but haven't coded for many years. I don't know how to code PHP.

7) what special tags in image are currently bothering you? And sorry, I don't understand the sentence "or at the preview function should render the images included using them.".
> Having looked ot [Image: ] it is useful, but beyond entry level users (and is difficult to find, install and enable). Ditto for [inline:xx] , with the added issue that page content below this tag (such as footer information) wraps up to the right of it rather than staying below it. RTEs such as TineMCE and FCKedit display these tages as text only, rather than rendering and image. So I think that clean integration of image handling with an RTE (or many) may be required to get the functionality required for entry level users and/or newbies.

8) dunno, should you roll a patch against image or drupal core's input filter? Or taxonomy?
> Don't know about the patch. Installing a feature and then having to hunt round and enable it in an input filter is really obscure. I would guess 9 out of 10 people installing the image_filter module would have a major problem finding this out and fixing it.

9) which dialogues and functionalities are currently not browser independent?
The image handling plugins (IMCE?) that work under both FCKedit and TinyMCE don't display correctly for me using Firefox, but they do with IE. The only dialogue box that displays correctly is the one invoked by BUEditor. However, BUEditor inserts an html IMG tag into the article (either need to allow this for Filtered HTML or use HTML format, and images it uploads are not treated as Drupal nodes/images, just files.

So a summary of the functionality I think is required - possibly in Drupal 7 core - is "simple image handling and display via a single module that can be easily enabled by selecting the module. Images should be accessed and catalogued via standard drupal features (filtered HTML, galleries, content display). Image handling functions (upload and/or insert into article and formatting within article; right, left, thumb, caption, size) should be available via a dialogue box popup that is available for both text entry and rich text editors (via API). This functionality would supersede and/or integrate that currently available from Image Assist, IMCE, image_filter, inline, possibly also Thickbox. The target user would be people who can blog and author text content but don't know HTML or coding.

See also http://drupal.org/node/207754 for a wider discussion on this issue.

Title:Integrated image handling with inline image display in contentUsability suggestions for image: Integrated image handling with inline image display in content

1a - fixed.

1b - you could write a bit of documentation; once you've done so I can wrap it in php and offer it as a patch to drewish.
I think you should include the version number of image (and possibly other needed modules), as I can see it getting rather rapidly out of date - image is getting better all the time.

2 - you could write a bit of documentation and offer that to the image_filter folks.
As to node ID vs. title: that's an image_filter problem - create an issue over there.

3 - check if there is an issue in the queue for that; if not, make a new issue and request it. (Anything with lots of suggestions - like this - isn't likely to get all the attention it'd need.)

4 - however, image_filter does this nicely. Add a note to that effect in the documentation (1b)

5 - http://drupal.org/projects/img_assist is another module; are you confusing that with http://drupal.org/projects/image module (+ image_attach, image_gallery, image_import)? If so, include a note to that effect in the image documentation ...
img_assist node creation is a problem for the img_assist folks, not for image.
image_attach and image_import both add images to drupal; one lets you browse (existing images by node title or images off your hard drive), the other imports everything in your "image import" directory.
You could add the hows and wheres for that in the documentation, although I've found both to be rather nicely thought-out, and self-evident.
image_filter handles the rest.

6 - please make a mockup of precisely what you mean and create a separate issue for it.

7 - image_filter is a problem for the image_filter folks. Dunno where [inline:xx] comes from, but you can take it up with the folks responsible for that module.
As to TimyMCE and FCKEdit displaying tags i/o images - create issues in their respective queues for it, if they're not already requested.
I expect you'll find that the originating modules (the ones working with [term:xx]) will need hooks ...

8 - so write some documentation, as in (2).

9 - that's issues for FCKedit and TinyMCE.

10 - image_filter does that very nicely.

11 - check the issue queue for image_filter; if it's not found, create a feature request for it, over there.

12 - image_filter does that very nicely. (I have no idea what a "MediaWiki image tag" is, though).

Regarding the need for documentation about filters etc -- please post a comment with the required information on the relevant book page & I will be happy to roll it in. Start here: http://drupal.org/handbook/modules/image

Regarding attaching multiple images to nodes: I keep thinking I'll tackle this one day... just need a free weekend, a lot of coffee, and possibly a bit of help from people who know the way the drupal database works better than me :)

Regarding getting image into D7 core: that would be cool. But things like multiple attachments need to be implemented first. Also, if we're going towards depending on Views (which I think we should), that means we can only enter core when Views does. But we should certainly aim to be "near" to core. I agree entirely that support for images is an essential part of a CMS.

Status:Postponed (maintainer needs more info)» Closed (fixed)

I'm going to close this.
Please file individual issues for single topics, searching for existing issues first.
Eg, multiple attachments is http://drupal.org/node/81102
For getting better image support into core, file an issue on core ;) (Though there probably already is one.)