Posted by jseffel on August 21, 2009 at 10:59am
| Project: | Image Browser |
| Version: | 6.x-2.x-dev |
| Component: | Code |
| Category: | bug report |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (works as designed) |
Issue Summary
If you expose filters in the view the form will redirect you to the start page when you hit the "Submit" button. This patch sets the correct action for the form.
File affected: js/imagebrowser.js
(Sidenote: Why not add the FCK-plugin to the downloadable package?)
| Attachment | Size |
|---|---|
| imagebrowser_js.patch | 507 bytes |
Comments
#1
#2
IBv2 doesn't really support exposed filters, which is why I'm holding off from applying this patch. Discussion about them here: #556920: No filters in 2.x?. We can revisit this once a decision has been made.
#3
This is wrong anyway, you should set the action through the Views API, not through javascript manipulating the form action.
#4
The original patch is broken in a couple of ways (it has no
js/subdirectory, and references a file calledimagebrowser_fix.jswhich doesn't exist):jp@drupal-staging-1:/var/www/drupal6-wrap/sites/all/modules/imagebrowser$ patch -p0 < imagebrowser_js.patchcan't find file to patch at input line 3
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|--- imagebrowser.js 2009-07-19 13:09:55.000000000 +0200
|+++ imagebrowser_fix.js 2009-08-21 12:54:32.000000000 +0200
--------------------------
File to patch: ^C
I'm worried that #556920-1: No filters in 2.x? has been pointing a lot of newbies at this patch for some eighteen months now, as an apparently straightforward way of implementing exposed filter support, and they're falling at this first basic hurdle.
Please find attached new patches, for WYSIWYG (tested) and for the original FCKEditor configuration (not tested, but I think WYSIWYG is the standard solution these days, no?) These have been created with
git --no-prefixbut should be fine for standard use withpatch -p0 <, but it'd be great to have them tested and get some feedback to make sure they're OK.#5
I still think that this is the better solution: http://drupal.org/node/556920#comment-2213998
#6
Maybe. #556920: No filters in 2.x? seems to have turned into bikeshedding about what the UI should look like (which arguably ought to be the current theme's responsibility, and the module should keep well out of it) so after ten minutes of reading up and down the comments I decided to re-roll this patch, which worked straight away.
(Edit: seemed a bit offhand. I do agree that in an ideal world Views API on the server is the neatest place to do it, and in-browser Javascript hacks should be avoided. But it is getting quite difficult to see what's going on and what's been properly tested in #556920; anyway, arguably a WYSIWYG stack is one big in-browser Javascript hack... :) )
#7
Hehe, yes, I agree with that. :)
However, Views actually has this API for a reason. The only thing you need to do is this:
<?php
$view->override_path = $path;
?>
I'd argue that this is better than searching the DOM for the right element and changing the attribute after loading the page.
#8
In case anyone's interested, I've updated the above patch so it works with another patch (423522-captions-image-browser.patch.4.txt) submitted to http://drupal.org/node/423522#comment-4978132 for adding Captions for Image Browser.
Cheers,
Victoria