Use Views for image browsing

Hey, thanks for all that work, really appreciated!

Rerolled the patch to current -dev version. KarenS, when you want to add new files, use 'cvs diff -N -up' ;)

Alas, I still have some points:

1) I reckon you wanted to leave some room for flexibility, but the empty default view is not user-friendly at all, because you'd have to manually configure items in the view using views_ui. Not sure how this could be improved, but perhaps an unfiltered view checking for an image_field of some sort...

2) I can't go ahead of displaying the thumbs, they have to be images linked to something? How did you set up the view for it?

Again, thank you for this powerful feature, hope to see it mature soon!

Gotcha: I was using Imagefield_crop (for testing the other issue)

It turns out that if_crop uses a different widget, so I changed file includes/imagefield_assist.views_default.inc from this:

if ($field['widget']['module'] == 'imagefield') {

to

if (substr($field['widget']['module'], 0, 10) == 'imagefield') {

and it worked. I'm not sure if this is the best solution, but it seems fine, since it will cover any widget from modules with names starting with imagefield.

I agree, this probably covers almost all possiblities. The check turns into:

if (substr($field['widget']['module'], 0, 10) == 'imagefield' ||
          strstr($field['widget']['type'], 'imagefield')) {

Forgot to attach the new patch

imagefield 6.x-3.2
views 6.x-2.6

The view results in pages, but is completely blank for each field.
Tried patched inc and original inc, cleared views cache for each.

Ran the query manually. It does work, but I had 25 or so fields at the beginning that were filled the NULL which is why it appeared to be blank so we just need to filter those.
Or perhaps its just my particular site but I don't think so, I created a new content type and new imagefield, added a new node with no imagefields and ran the query and pulled a record for that node.

I think that's the issue with using views for querying fields ATM that lourenzo spoke of earlier.

What the view is doing is to filter content types which have the imagefield and display thoes fields. However, they might be empty, as you have experienced, and that turns out to be an undesired output.

Maybe this can be solved with a query alter. Any ideas?

Using "WHERE" ala views filter.

The only thing I found was
Configure filter Content: photo (field_photo) - list
= TRUE
seemed to do the trick.

No, that won't work on situations where you have more than a field inside a Content Type, and one of them is empty.

Actually, I think this could cause trouble on more situations, unless you have only one imagefield in the whole site.

Hi, just wanted to mention I'm using the patch from #10 with beta3, and so far so good! Will let you know if I have any issues. Thanks for your work.

Andy

Just a reminder for testers who experience a blank popup after applying the patch: do clear your Views cache. It may help. (Site Building -> Views -> Tools tab -> click Clear Views' Cache .)

I've applied the patch in #10, and I'm having 2 issues:

* I don't see any exposed filters on the default view. Should I? Or do I have to add those myself? (Makes sense that I would have to add them ...)
* After applying the patch, whenever I insert an image, it always inserts the same one (fid=20). It doesn't matter which image I click; the same image always appears in the Imagefield Assist thumbnail display, and it always inserts fid 20.

Drupal 6.15
Imagefield Assist 6.x-1.0-beta3
Views 6.x-2.8

Thanks!

Subscribing

Patch failed:

$ patch -p0 < imagefield_assist-613968-views_0.patch 
patching file imagefield_assist.info
Hunk #1 FAILED at 3.
1 out of 1 hunk FAILED -- saving rejects to file imagefield_assist.info.rej
patching file imagefield_assist.install
Hunk #1 succeeded at 38 with fuzz 1 (offset 1 line).
Hunk #2 FAILED at 58.
1 out of 2 hunks FAILED -- saving rejects to file imagefield_assist.install.rej
patching file imagefield_assist.module
Hunk #2 FAILED at 853.
Hunk #3 succeeded at 1750 (offset 192 lines).
1 out of 3 hunks FAILED -- saving rejects to file imagefield_assist.module.rej
patching file includes/imagefield_assist.views_default.inc

i've installed imagefield_assist-6.x-1.x-dev

some hints?

I get the same. Did you solve this?

I believe it is because it was already commited...

@franz
no, there is now changelog for adding view and i can find no code for the view in the module.

Is there any date set for adding Views support to an official release?

Thanks!

@Jehu
It wasn't commited (I didn't find that on the changelog as well)

The code has change a lot, so the patch needs to be rerolled...

subscribing

subscribing

Subscribing.

Having views support or not will decide if I use this module or some other.

Having views support or not will decide if I use this module or some other.

What do you have in mind?

I second "bibo" above. People don't just dump images in random ImageFields. They usially organize them in galleries. And what better way to browse through a set of galleries than Views? In a multi-user site with each user posting many images, it is absolutely critical to be able to select "images that belong to this or that user", "images that are newer than ..." or any other arbitrary criterion. All these things are easily done using Views and a nightmare to support without Views.

I think I'm going for imagebrowser. It was originally build for image-module, but the 6.x-2.x-dev branch seems to be having to have some kind of filefield & imagefield support, and it's actively worked on (I think).

At least the module UI, functionality and flexibility seem to be what I need. I haven't tested the latest dev yet, but I think it's views-layer allow (or will allow) for any image-type files to be browsed and inserted via a wysiwyg plugin. Going to test this properly in the coming days.

More info:
http://drupal.org/node/366072
http://drupal.org/node/507242

Here's also a (incomplete but decent) listing of similar image inserting modules:
http://groups.drupal.org/node/21639

Ok, my opinion now after a very short testing phase with the new imagebrowser-module (2.x-dev):
Go with it! Works great out of the box with all and any images :D!

I've rerolled against the above patch against the latest dev version (2010-Jul-11).

Unless I'm mistaken, ImageBrowser does not allow you control the upload path nor does it have the ability to allow manipulation of the image after upload (changing it from the left to the right, or setting a different imagecache preset, etc). With Imagefield going into core in D7, I think this module is the way WYSIWYG inserts will go. Views support (with KarenS and franz's patch) vastly improves this module. (Exposed filters to search through images = dead useful!)

I've tested this and don't have any problem so far. From reading above it looks like the problems have only been with rolling the patch against updated versions so it would be great to get this rolled in! Hopefully this update will help move that along?

@franz
btw what was the purpose of removing command to delete the imagefield_assist_count variable during uninstall? I left it in the patch because you had but I didn't see what purpose it served.

Ah crap I spoke too soon, as pointed out in 18, no matter which image you select from the view it always returns the first one to the WYSIWYG editor. I'll look into this.

edit: K, it's something wrong with the default View. The way it creates relationships but doesn't uniquely name them seems to be to blame. The fid just isn't filled in so it picks the first one by default. I cleaned up the relationships to just use the one Imagefield type I had designated for this (the ifa_upload type that comes with this module) and it works fine now.

I'll see if I can fix the default that it creates, that should be pretty easy.

I rolled the patch into the module and reinstalled the module, but the view is not getting generated. I'm using views 2.6, so I imagine there isn't an API problem, the .inc file shows Views 2 as the $view->api_version = 2; but I'm not sure why the view is not generating. Any ideas? I am working on making it by hand, so if I could get an export dump from views that would be even better.

Searching with views would be super useful - that's the functionality I'm looking for. Thanks presleyd for submitting this patch. I think this will be great when it truly works out of the box.

Did you uninstall the module or just disable it and reenable it? I've used it on 3 sites now and it's always generated for me.

subscribing

Tagging. Starting to test patch now.

Here's some of my initial observations.

Love that you loop over and find every imagefield and setup the default view that way. It's a fantastic way to get up and out the door immediately. But, what happens when people drush down an entire site with modules? The specialized relationships required, and the double content field requirements as well, wont' exist. I understood how this worked because I reversed the existing stuff. We'll need heavy documentation to show people how to add different field associations later. I don't think it would be out of the question to drupal_set_message with a warning that the view will need updated (and a link to the handbook) when people add a new field of type imagefield.

Without changing settings, I see some odd behavior on the preview of the view. It's by default setup for 4 columns. I set those 4, but every column, contains every picture. Every picture in a column links to the same image. The link generated, includes divs that wrap every picture.
-.field-content
--.field-item field-item-1 (Image #1)
--.field-item field-item-2 (Image #2)
--.field-item field-item-3 (Image #3)
The solution for this was to off group multiple values.

I'm seeing empty

And, I may be loosing my mind. But I don't have the view pulling up in the WYSIWYG assist.

Subscribing

Subscribing

Can the patch above be rolled in a release please? I am not a Linux user and can access my site admin only through cPanel so applying a patch is not an option for me. Thank you!

Try using another operating system then.
http://drupal.org/node/60179

Thanks, but I noticed the patch works if applied to a Jul 11, 2010 dev version. The current dev version is from Feb 25, 2011. Who knows what changed in the meantime...

In fact is there a reason for the patch not being rolled into a release?

Added to 6.x-1.x branch, tagged as 6.x-1.0-beta4 and released.

I've tested, and everything seems to be working well, please let me know if any problems happen.

Thanks a lot, I'll test now...

Works very well, thank you very much!

I thank you too, and all users.