Integration with Image Browser

I'd like it a lot if imagebrowser were possible to use with FileField Sources. So far I've not had a chance to look at the way it works, but considering it's hard-coded to work with FCKeditor, I'm doubtful that I'll be able to make it work. Anyway, yes it'd be great to have it work, but I don't think it's possible at this time.

Wiki page summarizing the different projects on ImageField and WYSIWYG editors : http://groups.drupal.org/node/21639

Hi quicksketch,

Hopefully the IB2 API will make it easier for you to integrate?

http://drupal.org/node/523714

I'm happy to discuss anything else that needs to be done :)

Oops and change the status..

Hey Starnox, thanks for your input. The JavaScript API will indeed make it at least possible to use FileField Sources and Image Browser together, but there's still a serious limitation in the way ImageBrowser builds its lists of files. FileField Sources needs to be able to affect which files are available within the browser, since being the the "files" table alone is not enough, it needs to be able to filter down to files referenced by FileField, since these are the only files that are managed by hook_file_references() (preventing accidental deletion of images that are in use in multiple places).

It could be slightly possible to try to use the two together with the API as it is, but there'd be a lot of files listed that aren't allowed to be referenced. This is fairly similar to #438940: Add ability to use file uploaded via FTP, where Image Browser would list files that are unsafe to reference (say in case the node was deleted, you don't want that file deleted if it's in use elsewhere).

A clever user might then try to prevent this problem by editing the "ib_browser" view and filtering it specifically to files available through FileField. However, this would then break the normal file browser used by Image Browser within FCKeditor.

So the addition of the JavaScript API is welcome and makes good strides towards wider compatibility, but a module like FileField Sources will need not only a JavaScript API, but also an API to affect what files are listed.

FileField Sources also needs a way to disable options that are unnecessary (see screenshot). Uploading through Image Browser also doesn't have much use when combined with FileField, since FileField is responsible for ensuring that files are uploaded into the proper directories.

So in the ideal world you would want:

1. API to allow you to specify a View and therefore restrict which files are shown.
2. API to remove the insert window so when they click on a thumbnail it 'inserts' that image.

Is that correct?

What variables do you need returned? Just the fid?

I'll have a play with views, looks like I'll have to write a custom filter function... not sure how easy that will be :)

Just thinking about it, it's a bit of a nightmare. Obviously Views works mainly off queries. But I can't see anyway from the database alone to return a list of files just referenced by FF.

The only way I can see it working would be to get a list of files in the db, then cross reference those results in the filefield_get_file_reference_count() function, if the count is greater than 0 then we can show the file to user.

However that's going to be pretty rubbish performance wise.

Also is it worth integrating with FF or should we go straight to ImageField? Since Image Browser will only be returning images?

After thinking about it some more, I found that it might be possible to work even with the ability to specify a different view, since we could potentially use hook_views_query_alter(). However, it'd still be good to have a completely separate view for administration clarity.

Both the requirements sound like the most we can hope for. It'd be truly ideal to be able to control the list of files themselves, but given a view, we should be able to add appropriate filtering.

What variables do you need returned? Just the fid?

Yep, that's all we need!

The only way I can see it working would be to get a list of files in the db, then cross reference those results in the filefield_get_file_reference_count() function, if the count is greater than 0 then we can show the file to user.

Yeah, it probably won't be real easy, since CCK stores the FIDs that are in use across multiple tables. I'm still figuring out how we can do this efficiently (it might come down to a separate table like upload.module does). But don't worry, that's a problem for FileField to fix up.

Also is it worth integrating with FF or should we go straight to ImageField? Since Image Browser will only be returning images?

ImageField and FileField have identical database storage. We'll probably restrict Image Browser to working only with ImageField widgets as a cheap way of getting only jpg/gif/png images, but there's nothing that we'd need to do differently to support the two of them.

Awesome. So I'll get to work on a better API which allows control for different Views, and different requirements when 'inserting' images.

Then we can worry about getting the specific files allowed to be used for FF at a later date.

Here is a simple implementation of the IB source. It does not solve the problems mentioned in #7, so I manually deactivated the upload and delete buttons in IB in my local copy. I also don't use IB on textareas, so this is okay for me. I know it probably doesn't help you much, but I thought perhaps someone can use it in the same limited way as I do. Just extract to the sources directory.

If you give me some hints, I could perhaps also work on the IB changes and submit patches.

btw. wouldn't it make most sense if IB would manage it's own references?
It could save the fids that are embedded with tags at node_save time to a seperate table, and implement hook_node_references() with these then. This would also delete images that are not referenced through tags anymore, which makes sense. We don't need the delete button anymore then. The Upload button could create a reference on upload-time when it's called from filefield_sources, if you do not want to create references through sources (though this is dirty, IB could remove it again, when the node is deleted). What do you think?

FYI, I submitted a patch trying to implement reference counting here http://drupal.org/node/618838
I would feel better if you could have a look at it quicksketch.

forgot status change.

Scroogie, I just tried the patch and it works fine for me. Thanks for your work, i hope it will be added soon.

I spoke too soon. I try to upload a picture, and now i have a message :
"Referencing to the file used in the Visuel field is not allowed." (Visuel is my image field). What's that means?

bricef: Are you referencing files uploaded by a different field instance?

I try to used Image Browser uploading system, but it won't work so i will disable this option in my website.

Yes, you cannot use images that were uploaded with ImageBrowser currently. That is why I wrote the reference counting patch. I hope that all modules will implement reference counting in the future, so we can rule these problems out. I also hope that we get a unified storage for that #630310: Provide API for unified reference storage so we can use it in Views etc.

Coming back to this issue since a looong time, I'm still very much interested. As the file API change was declined for Drupal 6 (it is still in the works for D7 though #353458: hook_file_references() was not designed for a highly flexible field storage), we need a different way to seperate reference-managed files from unmanaged files. Like we discussed in a different thread (don't remember the id), we could e.g. copy the files that are used through the imagefield (not really nice though).

Scroogie : what exactly are the files you attached? How can we use them to implement Image Browser in File Field?

kevin: It's a source plugin for the filefield_sources module. You can extract the archive to the sources directory and enable the source afterwards. I didn't work on it anymore, because the maintainers of filefield_sources and imagebrowser don't seem to be interested currently. Perhaps it can be resurrected some time in the future.

Scroogie : Okay, so it does not provide direct functionality at this time, and is a starting point for the module maintainers should they become interested?

At the time I wrote the patch, it provided the functionality to choose an Image through ImageBrowser, so it really provided the functionality. It had the same problem as other plugins though, namely that ImageBrowser does not maintain reference counting, so it only worked for images that had been uploaded with Filefield. However, perhaps ImageBrowser changed in the meantime, so the source might be unusable at the moment.

If you can find out what happened to the http://drupal.org/project/wysiwyg_image module, it promises to do everything!

+1 I very much want this functionality. An initial test of scroogie's source plugin from #13 with Image Browser 6.x-2.x-dev (7/10/10) shows an Imagebrowser link but does not do anything. My images have all been uploaded with Filefield. Anyone have this or this method #507242: Created CCK Image Browser field, need support working?

subscribe

+1

subscribe

It is pity that nothing is doing here...
Image browser has really good interface for this.

Considering the apparent death of the module (no D7 version yet, despite it being out for almost 2 years), I don't think this will be added to the project.