Updated: Comment #15
1. Install drupal and edit the frontpage view
2. Click to edit the first filter under "Filter criteria"
3. Check "Expose this filter to visitors, to allow them to change it" checkbox
Nothing happens. I think it should provide more options. Also, after clicking Apply and repeating step 2, the checkbox is not checked anymore.
(from Jan 26 2014 in 2182109)
?
?
No.
No.
#1851414: Convert Views to use the abstracted dialog modal
or
#1342198: Use .on and .off instead of .bind, .unbind and .delegate
#2217551: Cannot expose a filter in Views UI
#2182109: Exposed filter setttings not working
#2145147: Impossible to define an exposed filter with views ui
| Comment | File | Size | Author |
|---|---|---|---|
| #16 | 2130205-16.patch | 3.62 KB | damiankloip |
| #13 | drupal-2130205-13.patch | 5.12 KB | rbayliss |
| #1 | drupal-2130205-1.patch | 4.52 KB | olli |
Comments
Comment #1
olli commentedAdding '#ajax' everywhere makes it work, but I dont think this is the correct solution. Views used to do this automatically before the dialog conversion.
Comment #2
Peter Muusers commentedI just ran into the same issue and used the patch, which seemed to perfectly solve the problems I had.
Comment #3
s_gupta_14 commentedPatch solves the problem for me
Comment #4
catchMarked #2145147: Impossible to define an exposed filter with views ui as duplicate.
Comment #5
dawehnerI am really sure that this is rather more a bug in states.
Comment #6
nod_It doesn't use #states, checking the box makes an ajax request that is supposed to replace the form. LTried a couple things, all I ended up with is a redirect to a page displaying the json of the ajax callback.
Comment #7
nod_Not a javascript issue. Patch fixes the problem.
Or if it's an issue with the JS it's a views_ui issue that's related to JS. Right now it looks like the ajax form isn't prepared properly and the js triggering the submission submit an actual form, not an ajax form.
Comment #8
andyceo commented1: drupal-2130205-1.patch queued for re-testing.
Comment #9
dawehnermhhhh
Comment #10
wiifmI can +1 for the patch in #1, it solved the issue I was having.
Comment #11
tim.plunkettSo this fix works, as people have said. But it seems like it should not be needed, and it also uses a procedural function that I'm pretty sure we want to kill.
So what is the way forward here?
Comment #12
dawehnerI would really like to know why this is a bug in the views_ui module. We haven't changed our usage of the code ...
Let's try to find a solution either in PHP or the JS side of the ajax system.
Comment #13
rbayliss commentedAn alternative solution that avoids using current_path().
Comment #15
yesct commentedComment #16
damiankloip commentedHere is a reroll with the code from DisplayPluginBase removed, since we removed the theme stuff a little while ago.
I agree with Daniel that it would be nice to fix this in a more generic case. However, I think this may be an artefact of the modal conversion? And the views UI "Checkboxifier" is pretty views specific.
Comment #17
damiankloip commentedComment #18
lauriiiTested this manually, seems to fix the described issue. I recommend this to be RTBC.
Comment #19
dawehnerI really really hate that we need to do that, though let's be pragmatic for now.
Comment #20
webchickConfirmed this fixes the bug. However, as a developer, I never would've guessed in a million years that adding a magical class to my form element suddenly made AJAX work. Let's get a follow-up to take a look at the AJAX API and see if there's a more obvious/easier way for modules to register with the system, so this bug could've been avoided.
Also, since we're no longer doing current_path() here, un-stakling Crell.
Committed and pushed to 8.x. Thanks!
Comment #22
nod_@webchick: #1533366: Simplify and optimize Drupal.ajax() instantiation and implementation.