Use Views for image browsing
| Project: | ImageField Assist |
| Version: | 6.x-1.x-dev |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | needs review |
I wanted more flexibility in the browser, paging, more control over filters and sorts, etc. The logical solution is to use views for the browser since anyone can adjust the view themselves to cover their particular needs.
Attached is a patch to add this in (the patch is not against a current version, but it is a simple patch that should not be hard to adjust). I'm also attaching the default view, which would be added as a separate file in the includes folder. The default view file needs to be renamed to remove the .txt extension.
The default view finds all imagefields and adds them to the default view automatically, sorts by creation date descending and adds paging and ajax support so it will work in the popup window, and displays it in a grid. I figured that basic view is enough for the module to include, users can then adjust the view to add other filters and sorts, change the number of items per page, or whatever.
| Attachment | Size |
|---|---|
| imagefield_assist.views_.patch | 2.99 KB |
| imagefield_assist.views_default.inc_.txt | 3.95 KB |
#1
Oops, one mistake. We don't want multiple value fields to be grouped, we need to see all of them. Use this default view instead.
#2
Didn't mean to mark it reviewed and tested, hit the wrong item :)
#3
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!
#4
The default view, as it is set up, does everything exactly the way the current code does it, so you get that behavior with no additional work. It looks for image fields and adds them to the view, etc. You should not have to do anything for it to work, it is all in the default view. It works perfectly out of the box for me. Did you clear the views cache to get a fresh view?
#5
Also, if you have altered it, you are no longer seeing the default view. If you see an option to 'revert' the view on the views list page, you have altered the view. Revert it, clear the views cache, and then it should automatically find the right image fields and content types for the view.
#6
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.
#7
That should work fine, but you might go one step further and check if either the module name or the widget name start with imagefield in case there is some foobar module creating an imagefield widget (since widgets can be created by any module). There could still be modules that create imagefield widgets that don't use imagefield in either the module or widget name, but there is no foolproof way to find them. Checking both the module name and the widget name is probably as much as we can do automatically.
#8
Er, I meant to say check if the widget name *contains* 'imagefield', to cover something like a foobar module creating a widget called 'foobar_imagefield_fancystuff'.
#9
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')) {
#10
Forgot to attach the new patch
#11
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.
#12
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.
#13
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?
#14
Using "WHERE" ala views filter.
The only thing I found was
Configure filter Content: photo (field_photo) - list
= TRUE
seemed to do the trick.
#15
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.