Image attach: make drop down to autocomplete

I agree. Replacing the select box with an AJAX auto-complete textfield would make Image Attach a lot more user friendly. Is anybody planning to work on this functionality?

How is http://drupal.org/project/image_attach_browse ?

A seperate module may be more versatile, to not to flood image module too much.

http://drupal.org/project/image_attach_browse looks promising. Closing this.

image attach browse is all well and good, but i don't want to browse 9,000 images: i want to auto complete from the node title. is there a way to make that happen?

Hi,

I'm re-opening this feature request mostly because of three reasons:

1. The initial problem posted by yngvewb on October 29, 2008 is still unsolved: "Large" collections of images are unmanageable through the "Existing Image" drop down menu of Image Attach. Already a moderate amout of image nodes causes a significant delay when editing nodes with attached images; I found a de-facto limit around 20,000 image nodes on a dedicated server, opening the node edit form takes about one minute in such environment. On another site I have some more images nodes, and thus had to disable the "Existing Image" feature. That is a really bad thing since Image Attach is IMHO one of the most important features of Image module (allowing to attach existing images to different nodes; I don't know if this currently is even possible with CCK-based Image handling). Replacing the drop down menu with an autocompete field would allow to use Image Attach again on such Image-heavy sites.
2. The mentioned module Image Attach Browse does not solve the performance/load problem for Image-heavy sites; it is solely a usability enhancement for sites with very small amounts of images.
3. Having the necessary move of Image module to Drupal 7 in mind, an autocomplete field seems like the natural choice; Image Attach for Drupal 7 could be implemented as an "Image reference" field (analogue to the existing Node and User reference fields in CCK); the display formatter would run through the core Imagefield and Imagecache

Since there are already a couple of similar requests: Has anyone posting on this thread found a working solution in the meantime?

Thanks & greetings, -asb

Hmm...

I'd rather see efforts going into making Image Attach Browse scalable, eg using ajax to load only a page worth of thumbnails.

But I'll consider a patch for a setting at admin/settings/image/image_attach to use an autocomplete instead of a dropdown.

This can have taxo and thumbs support also like in Image Assist.

We have ~15,000 image nodes and none of them are neither reusable, as one can not know which name is which picture, nor findable, as it is impossible to implement a schema for picture naming, as titles must be human readable and differ for various contexts. Believe me, we have tens (if not hundreds) of pictures which belongs to a same logo, item or smt. Our editors always prefer to upload a new one. It is horrible to have tens of copies of the same picture with slightly differing names. Just a waste of everything really, even a bad reputation for the readers who are browsing the galleries and seeing variants of the same picture again and again (and again).

Also IA Browse is very simple for now. Newest code of IAB shows some signs of a future filtering implementation btw.

BUT, Image Assist's pop-up is perfect already.

> This can have taxo and thumbs support also like in Image Assist.

And ponies.

If you start adding taxonomy to the mix, then you have bits of the form that are conditional, more complicated ajax and querying, and so on. At which point, you might as well start thinking about embedding a View to work as the selector widget. And given different sites had different needs, what we're talking about here is basically CCK widgets. Which I really don't think is a worthwhile thing to work on for Drupal 6, at least for me.

I'll review patches. If someone does have the time and energy to embark on pluggable widgets, remember that whatever we do here has to be easily upgradable to FieldAPI on D7.

@joachim:

Thanks for (re-) considering this feature request!

I'm absolutely not fixated on autocomplete fields, they're simply pretty robust and well established in the Drupal community. And hopefully easy to implement ;)

Most important to me is the scalability part, especially to be able to allow users/editors to access Image Attach - on sites which I'm maintaining as single editor, the re-use of existing images is disabled by default (for performance reasons); if I need to re-use an existing image, I enable this feature temporarily at ./admin/settings/image/image_attach. Being able to re-use existing images without sacrificing the website's performance would be a huge improvement.

The second priority is the usability part; to quickly and easily find the right image defilitely isn't trivial with drop down menus. I think embedding a View could help (e.g. narrowing down a selection list with exposed filters, similar to Views Bulk Operations); and indeed, there are a couple of nifty Ajax widgets to preview thumbnails when hovering over a (text) link etc. However, searching for and implementing a pretty solution sounds like a fair amount of work - thus I'd prefer a quick fix ;)

Greetings, -asb

Wouldn't it be sensible for people with greater needs to look at moving to cck nodereference.module, which as you say, already has autocomplete and is already being worked on for Drupal 7. Of course, I'm assuming that it would be trivial to write a script to move Image_attach to nodereference ;-)

#475774: image attach: the future
http://groups.drupal.org/node/25144
#533222: node and user reference fields in D7 - maintainer needed

comment-2679752 - true, sigh...

After reviewing the current Image Attach 6.x-1.0-beta5 in recent Browsers (e.g. Opera 10.53/Win, FF 3.6.3/Win) I noted, that my old "workflow" (Image Attach disabled by default; enable it "on demand") doesn't work anymore on image-heavy sites. Loading a node editing form with Image Attach enabled simply kills the browser (it doesn't respond for several minutes and has to be killed through Windows Task Manager or the Linux 'kill' command).

Some statistics:

• 25746 image nodes (total: 53097 nodes) - Browser dies, attaching images impossible
• 20775 image nodes (total: 34126 nodes) - Browser dies, attaching images impossible
• 8798 image nodes (total: 11347 nodes) - Loading node edit form takes about 70-90 seconds, attaching images is possible
• 2657 image nodes (total: 14518 nodes) - Loading node edit form takes about 80-100 seconds, attaching images is possible
• 150 image nodes (total: 750 nodes) - Loading node edit form takes 15-20 seconds, attaching images works smoothly

So the "sweet spot" where 'image_attach' runs smoothly is on sites with about 100-1,000 images. Those figures were measured on different dedicated server with 2-4 cpu cores and 4-8 GB of RAM (not directly comparable, but a tendency is obvious); the sites run at a php_memory_limit of 150M-200M. Having more system RAM oder a higher php_memory_limit does not convice 'image_attach' to load it's drop down menu or to complete opening the node edit form on the image-heavy sites.

In regard to the functionality of attaching images I'd consider this as "critical", thus adjusting the priority. If there's no one willing or able to fix this for 'image' module 6.x-1.x, please state so and set to something appropriate like "won't fix".

Thanks & greetings, -asb

I've added this to the top of includes/form.inc:

// hetta added:
set_time_limit(0);

(the "hetta added" means that I remember to transfer this bit between drupal versions ...)

That means that the form doesn't time out. It might run on for minutes and minutes, but it gets there. (I have some 15000 images). I'm phasing out image_attach altogether - I have only about 150 attached images left in the database. Being the only editor on my site, I use image_filter instead. Unfortunately, image_filter requires the node number of the image.

@Hetta:

Thanks for pointing me to image_filter; it seems to be a very useful module that might help me to solve issues I had with embedding 'image' module's images with my default input format ('mediawiki_filter') for years.

However, even if 'image_filter' might be considered as a woraround, it doesn't really solve the scaling issues of 'image attach' ;)

Greetings, -asb

@asb: yep, image_filter instead of image_attach is a workaround. It's better than nothing, though, and I expect I'll move to whatever image supplies out of the box, once d7 comes around.

(There are other scaling problems in drupal: taxonomy is an enormous drain of resources if you have more than, oh, 10000 taxonomy terms. The book node scaling problems seem to have been solved with the recent d6 sub-tree thing.)

duplicate of #475774: image attach: the future