I have a view (content pane) which provides an exposed filter. It allows panel to override the title and use exposed widgets form as pane configuration. The view receives filter value from a panel. The panel passes a keyword/token to the view, but the view receives the keyword/token unsubstituted. Is it a bug or was it designed that way?
If this is a bug, I found a quick fix by altering "ctools/views_content/plugins/content_types/views_panes.inc" line 286 :
if ($allow['exposed_form'] && !empty($conf['exposed'])) {
foreach ($conf['exposed'] as $filter_name => $filter_value) {
$conf['exposed'][$filter_name] = ctools_context_keyword_substitute($filter_value, array(), $contexts);
}
$view->set_exposed_input($conf['exposed']);
}
| Comment | File | Size | Author |
|---|---|---|---|
| #5 | error_catching_keyword_substitution-1686868.patch | 724 bytes | iSylence |
| #2 | 1686868-keyword_subtitution_in_exposed_filter_form.patch | 674 bytes | gantenx |
Comments
Comment #1
merlinofchaos commentedThis isn't a bug; The exposed filter forms were never intended to support keyword substitution. Contextual filters can, but not the exposed filters.
Comment #2
gantenx commentedThis feature would make exposed filter in view pane more flexible. It can combine any filter operator with dynamic filter.
The idea is to subtitute keywords in every exposed filter value before Panels send exposed filter values to the view.
Any plan to include this feature into Ctools? I attach a patch.
Comment #3
gantenx commentedComment #4
iSylence commented+1 Patch works great!
Had the exact same problem, wanting to use keywords in Views but not being able to, be great to see this feature in Ctools! :)
Comment #5
iSylence commentedFound a small issue where arrays were being passed in as keywords and were throwing errors because of this.
Changed patch to not do substitution if an array is passed in as the keyword.
Comment #6
gantenx commentedWhat are you using as exposed filters?
Comment #7
iSylence commentedIt is a multi-select taxonomy term which happens to pass in an array rather than a string, hence the need for the follow up patch.
Hope this helps.
iSylence
Comment #8
merlinofchaos commentedit's small, but the if() violates code style. It should be if ()
I'm still not completely convinced exposed filters should be using keyword substitutions.
Comment #9
bradjones1"I'm still not completely convinced exposed filters should be using keyword substitutions."
That begs the question - why not? I found this ticket in an effort to satisfy the following use case, which might provide a justification: I have a page that's essentially operating like a search, where the panel's url is in the style of search-panel/%searchterm, where %searchterm is a string context. I can't use a contextual filter because contextual filters lack an operator like "contains any word" which is available to an exposed filter.
Perhaps there's a more elegant way to do my specific use case, but I think the folks looking for this functionality are doing so not because they love exposed filters per se but because they offer some options absent from the usual data flow (e.g., contextual filters.)
Comment #10
Anonymous (not verified) commentedThis would be awesome.
Comment #11
acbramley commentedHave been using this patch for a long time on a live site and it works well RTBC
Comment #12
stella commentedI also needed the same functionality. My use case is that I'm using panelizer to control the layout of a certain content type. I don't want the editor to have access to the panels or pane configuration. Instead I've given them a drop-down on the node edit form. The value of that drop-down entry is passed to the embedded views_content pane using tokens which changes the content of the view accordingly.
The above patch works great for my use case, so +1.
Comment #13
paean99 commentedJust a little test and Patch #5 is working for me. I have to test it more extensively.
I think that it is a very good idea. To reinforce the patch, i will try to summarize my use case:
I need a content type A, editable by the users of the system, which will serve to model the needs of external clients of those users.
One of the factors to that modeling is the ability to add a list of Content B to Content A. A good analogy is seeing this list as Products Line items in a cart. Others fields in Content A will represent other Line item Types.
The user has to be able see a view of Content B and choose some of them (i can use VBO or Rules link for the 'choosing' and a View Content Pane for the view in the same page).
But he also need to be able to filter the view and later when he comes back have those same filter values saved, since they are an important part of the modeling.
One way to accomplish this is to have the exposed filters parameters in others fields of Content A and passing their values as Substitution patterns to the exposed filters of the view pane.
Field Embed Views is a module that do a similar job, but unfortunately it creates his own field type and i loose much of the power of drupal to manipulate, without code, the exposed filters fields and views.
Entity Reference View Widget and others do not save the exposed filters values or so i think.
With all of this, what i finally have is similar to a new entity: a 'Fieldable View' with saved exposed filters (fieldable view searches as content). And without a custom module...
Edit: To be fair, i have to mention these two alternatives that may contradict the necessity of the patch in my case:
Views Saved Searches and moving away from Views Search API saved searches. I haven't tried them yet, but they seem to be good options.
Comment #14
mrjmd commentedComment #15
japerryDue to popular demand (and also a personal need for this in COD), I'm pushing this in. Also fixed the code issues ('if()'.. there were two in this file)
Fixed!
Comment #18
papagrandeFixed the typo in the title for better search indexing.
Comment #19
kopeboyIs there a way to use this with Grouped filters?!
Like pre-populating them in the View configuration with context keywords that will then be substituted by Panels?