Imagecache Image assist counterpart module

...except that I wish that Image Assist also supported content types that use imagefields / imagecache. And this is for in-body insertion of images + image re-use.

This sounds like the inline API that Sun's been talking about. http://drupal.org/node/80170

afaik it's fairly well specced, but not a lot of code yet. So would be worth seeing if that could be turned into a GSoC project.

I've been trying it out and so far it appears quite promising.
What would be ideal to me is to put more developers on it or maybe agree on an extension structure. They appear to have an integrative attitude - integrate imagecache, and so on.

If a decent team would be working on this - or another module that's worth it - given that one can agree on a vision - would sure make a kick-ass inline media handling (plus a core mediabrowser for all uploaded media files) hah, sweet dreams are made of these...

Life is a process

This is also already covered in last years uLink project which provided a filter format for doing exactly what you described and has imagecache support, token support, and supports more then just image types.

Sorta, part of uLink was to do JS autocomplete on the filter as you typed it. ie, you could type [l|file/ and it would start doing an autocomplete with the files in your files table. It didn't do a graphical file browser of any kind. There is room to grow on this issue so I'm no trying to deter you, just provide useful information. uLink is also a little harder then point and click which might be more intuitive with some sort of file browser. There are a lot of filters out there, inline, uLink, etc. It would be nice to get all of this sorted out.

There's a lot of posts here to the effect that "X module already does Y part.." Is there anything here we can actually propose as a SoC project?

This could be a good SoC project if it builds on existing solutions and aims for a good UI. Who has been really happy with the image assist UI? I think a simple and intuitive way of interacting with images would be a big win. The proposal needs work.

Thank you to everyone who responded thoughtfully to my proposal!

I'd like to respond to everyone's questions at once. If you feel your feedback has not been addressed, please let me know.

Use case: A user wants to easily add inline to a post, images that exist on the site as CCK imagefield content, and specify an imagecache preset for the display of those inline images.

The goal of this module is to provide functionality that allows the user to:
- browse existing CCK imagefield images visually -- (using thumbnails of the images)
- select an image and specify an imagecache preset to be used when displaying that image.
- Specify a point in the body of a post and insert that image and imagecache preset pair inline into the body.

The main functionality provided by this module would be an interface to achieve all of the above. This interface would communicate the user's selection of image and imagecache preset through a structured tag that would be consumed by the Inline module, which provides a filter for images and imagecache presets.
The interface should achieve a high level of usability. Usability testing could be incorporated into the SOC schedule.

The interface might provide the following filters for narrowing down the choice of images:
-node title contains (text)
-contains taxonomy terms (text autocomplete, select field?)
-My vs Other users' images

The module that provides functionality most similar to what's described here is image_assist.module. This functionality has been requested by several people in a feature request at http://drupal.org/node/208136 . Image assist does not work with CCK imagefield content. See the module review list below for more information about other modules mentioned in the discussion of this proposal.

Inline is the best choice as the module providing the input filter because its maintainer, sun (who also maintains image_assist) is working towards a carefully thought out Inline API. Inline API aims to be an extensible way of adding content inline to posts. An extensible Inline API contrasts with the use of multiple unrelated modules that provide proprietary input filters

Sun intends for the Inline API to integrate into Gábor Hojtsy's battle plan for a WYSIWYG editor in Drupal core ( http://hojtsy.hu/blog/2008-feb-04/supporting-wysiwyg-editing-better-drup...) .

For details about the Inline API, read http://drupal.org/node/80170 (description of the API) and http://groups.drupal.org/node/8707 (“sun's vision for handling embedded/inline content and Wysiwyg in Drupal”).

While this is project is *not* intended as a core contribution, I see it as the primary benefit that it would integrate with functionality intended for an accepted DRUPAL WYSIWYG system; this functionality is a type or component of WYSIWYG.

At http://drupal.org/node/80170 , describing the InlineAPI, sun said "A inline_assist.module leveraging this API is also worth thinking about (Obviously this would be based on the great work of img_assist.module and supersede it)."
Given that this project is related and may be the "next generation" of image_assist, is it best to wait for sun's feedback\work on InlineAPI, and thus not use it for GSOC this summer?

Modules mentioned in this discussion:

1. Inline (maintained by sun) – Provides an input filter
-Works with any image on a Drupal site (CCK or otherwise)
-Works with imagecache
-Will use the inline API: Extensible filter system, incorporates Gabor's Battle Plan for a Core WYSIWYG

2. Image Assist – (Maintained by sun) – Provides an interface
-The interface allows the user to:
--browse images visually
--specify a size (based on image.module's defined sizes)
--specify an alignment
-Funtionality is similar to what's being proposed here
-Doesn't work with imagefield, imagecache

3.uLink – Provides an input filter
-Has imagecache support
-Has extra features that are unnecessary to the project propose here, such as autocomplete
-Extensible filter system could be relevant material for sun's work on Inline API

4.Asset
-In my testing, I was unable to achieve a display of image thumbnails and am not clear that the module actually provides this. Can anyone attest otherwise?
-At 600+kb zipped, tis module is bigger than Drupal Core (and many of the images it's likely to manage)

5.(img Package) IMG filter
-doesn't work with cck imagefield
-instead, allows user to upload images as attachments to the node being edited
-Let's users specify image alignment
-uses custom filter (which makes sense given its functionality)
-Great module!
-Features are well documented!

In response to billfitzgerald's question about pluggability: What component(s) of this project do you think should be pluggable. Extensibility is one of the most important values for a Drupal project\component, and I see this module's "participation in extensibility" as being fulfilled by being built on top of Inline which will become the Inline API. Ideally, it would be built on top of the Inline API, but being built to use the Inline filter seems like the next best approach. Ideally, we would also have sun's input on all of this but as mentioned in this discussion, he is on vacation until the day after the GSOC application deadline.

Perhaps the interface could be pluggable in some way.

Part or all of the interface could be defined by a view with exposed filters such as search by title, search by taxonomy term, etc. Using a view offers the end user more complete control over the module's interface.

With a popup window that contains a list view, a jQuery event could bind to the click event for the .view-field divs containing the imagefield image and onclick, close the popup window and populate the image information appropriately into the body of the post.

Alternatively, the interface could be defined by a form (of course, modifiable via the Form API). This approach offers complete control over the interface to developers and makes it easier to update form elements asynchronously. For example: the available images display could be updated to show only those images that match the text in a 'title' search field as the user types.
A non-view based approach does not preclude the form from using views as components. For example, a custom form element could refer to a callback function that uses user-submitted data as filter text to be programatically submitted to a view and returns the results of that view as HTML.

After further thought, I think it would be inappropriate to proceed on this project without sun's involvement, since it would cover so much of his development territory.

Marking as 'rejected'.

FYI : http://drupal.org/project/imagefield_assist