Attached patch makes the exposed form available as extra field, so you can easily move it around e.g. put another field between the exposed filter form and the results.
The patch also fixes the path troubles, so exposed filter forms work also without ajax.
| Comment | File | Size | Author |
|---|---|---|---|
| #12 | eva_exposed_form_separate_field.patch | 4.41 KB | mkadin |
| #9 | eva_1301410_9_exposed-form-as-field.patch | 3.8 KB | johnv |
| #7 | 1301410.2.eva_.exposed-form-as-field.patch | 6.83 KB | joachim |
| #1 | eva_exposed_form.patch | 6.83 KB | fago |
| eva_exposed_form.patch | 6.5 KB | fago |
Comments
Comment #1
fagoPrevious patch had a bug, as
$view->display_handler->uses_exposed()requires initialized handlers to work. Fixed that.Comment #2
Turies commentedThanks for the patch. But I have problem that exposed filters field rendered on top of the page regardless of the weight of this field. Any ideas?
Comment #3
Turies commentedNevermind, it is fixed in the dev branch.
Comment #4
joachim commentedPatch works, though I ad to clear my cache to see the effects.
Perhaps this should have a hook_update_N() to take care of that?
Comment #5
fagoI'd be happy to re-roll if there is interest in including this patch...
Comment #6
joachim commentedAlso, the exposed form is showing above other (real) fields even though display settings have those higher up.
Comment #7
joachim commentedHere's a reroll with a fix for the problem with the exposed form weight -- the key in the build array needs to match what is set in hook_field_extra_fields().
Regarding the hook_update_N() -- it would actually mean adding a whole install file for just that (for now). Is it worth it? Should users expect to clear their cache on a version update anyway?
Comment #8
mkadin commentedI've recently become a maintainer of this module...this seems like a great patch, let's all take another look and mark it RTBC. I'll handle the hook_update_N piece. EVA's caching issues need a lot of attention anyway.
Comment #9
johnvPlease find an updated patch attached.
Regarding flushing the caches: that is not an issue of hook_update(), but eva_field_extra_fields(). It is not called every time you add/remove an exposed form.
I tried to set the exposed form field ALWAYS, and adding a 'visible' value:
That works (also, you don't need the update_N anymore), but the 'apply' is still visible (in my bartik theme). Therefor, it is not included in the attached patch.
(PS. It was nice testing this feature, but it doesn't help my use case. I want an exposed form in a Node edit page, and save the values together with the node.)
Comment #10
mkadin commentedThis looks good. I'm testing it now, others should do the same!
Comment #11
mkadin commentedNew patch attached.
Added a form alter to the views ui that clears the field cache when you save a view. This solves the problem of making sure that the exposed form field only shows when an exposed form exists for the view since after a view is changed and saved, field information will be rebuilt.
It solves the bigger cache problem as well: EVA views don't show up when first created unless the cache is cleared. This will clear the cache when the EVA view is initially saved.
Also a few small changes to the way the field is labelled on the 'Manage Display' tab.
Anyone want to give it a test / a look?
Comment #12
mkadin commentedAnd here's the actual patch from #11. It mostly comes from #9 and before. The technique for the form_alter on views save came from here: #974576: Is there a technique (hook?) To intercept the view when i'm saving it ?.
Comment #13
mkadin commentedThis has been committed to the dev branch. New release coming soon.
Comment #14
mkadin commented