Posted by SocialNicheGuru on March 31, 2009 at 3:31pm
17 followers
Jump to:
| Project: | Panels |
| Version: | 6.x-3.x-dev |
| Component: | Panel pages |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (works as designed) |
Issue Summary
I created a view
checked exposed form in block
created a panel page
set the panel url so that all links should go back to it
put the view and panel in the page
if you click on the submit button in my exposed form in block, I am taken back to the original view not the panel.
This shows the same behavior as: http://drupal.org/node/112552#comment-1192866
Comments
#1
This is a Panels issue. I'd re-file it but I don't know what version of Panels you're using.
#2
#3
I thought that panels was not recommended for production sites? Is this a development site? Does panels produce the exposed form in block option for a filter in views?
#4
views does.
I create a panels view pane
I hit the expose filter block
i place the view panel pane and the exposed filter block in a panel page.
i click on submit and the filter goes back to the view.
exposed filter elsewhere works just fine.
#5
The problem here is that the exposed filter as a block is just a simple, Drupal block. Drupal's blocks are dumb and have no sense of context, so it doesn't know whether or not it's in a panel. So it can't pull the URL from the panel it doesn't know about. The setting on the panel pane therefore cannot affect the exposed filters in a block.
#6
Would something like this work? any thoughts on how to modify to get the current panel's url setting (not familar enough with the panels api myself)
http://drupal.org/node/290691#comment-966163
$view = views_get_view('your_view_pane_name');$view->set_display('default');
$view->init_handlers();
$form_state = array(
'view' => $view,
'display' => $view->display_handler->display,
'method' => 'get',
'rerender' => TRUE,
'no_redirect' => TRUE,
);
$output = drupal_build_form('views_exposed_form', $form_state);
return $output;
#7
At this point they would not be in a block. They would need to be their own ctools content type, perhaps, which is probably ultimately the way to go in Panels.
#8
could i contribute somewhere to get this feature in? It is pretty crucial to the layout of my site and I wanted to use panels to standardize everything :) Panles is a kick as* module!
C
#9
How can a ctools content type be created?
#10
subscribe
#11
Better do it so:
function my_module_form_alter( &$form, $formState, $formId ){
if ( $formId == 'views_exposed_form' )
{
$form['#action'] = url($_GET['q']);
}
}
#12
This fix is working for me! Thanks :)
#13
SOLID fix. Thanks you so much, erikseifert!
#14
This worked great....
#15
Wow that was a surprisingly easy fix. GJ erikseifert and thanks.
#16
Subscribe
#17
As I understand, the issue is that when you expose the filters as block and want to add them in a certain area on every page on your site, the input that you provide to the block is not directed to the actual panel where you add the view.
I have solved my case with Panels Everywhere and Views content panes. The steps for setting up a site-wide exposed filter for me were the following:
1) Created a view with content pane display. The content pane has an exposed widget which I want to see on every page. I do NOT set the widget to be exposed as block.
2) I create a new panel page, add the created content pane to it and override the path for the content pane to have the panel path
3) In the site template provided by Panels everywhere I add the same views content pane again, and again I override the path to redirect my query to the panel page
4) In order not to have the content pane two times on the panel page (one printed by the site template, another by the actual page), I set the pane visibility on the site template to hide the pane on the panel page.
That's basically it, the solution is fairly simple but requires Panels Everywhere module.
Dm.
#18
In case of those just finding this issue (like me). Using much of the suggestion in #419556-11: Make 'exposed form in block' work in panels: Change the $form['#action'] of views_exposed_form to request_uri() in panels_pane and on referenced threads I was able to redirect my exposed filter block to the correct custom Panels page.
* View (MY_VIEW_NAME) of data with exposed filters
* Exposed filters in block setting is on
* Views Pane display of MY_VIEW_NAME is added to a custom Panels page with path 'my/panel/path'
* Exposed filters block is used in a custom Panels home page with path 'home'
If a Views page display is available, the exposed form will redirect there. If a Panels page is created and holds the Views pane display pane related to the exposed filters, it doesn't know where to go. By default, applying the filter form on the home page would reload the home page with the filter query attached (e.g., mysite.dev/home?keys=0&tid=1). The action on the form was set to '/' since I had no Views page display.
When I used code from #419556-11: Make 'exposed form in block' work in panels: Change the $form['#action'] of views_exposed_form to request_uri() in panels_pane above it affected all of my exposed filter forms and I needed to restrict it to the specific View in question. Using a suggestion from merlinofchaos elsewhere, I first check for the View name to make sure we only apply to exposed filters of this View.
The exposed filter form now has an action of 'my/panel/path' and redirects properly with the required query string attached. Any suggestions on cleaning up the following?
<?phpfunction MY_MODULE_form_alter(&$form,$form_state,$form_id){
if ($form_state['view']->name == 'MY_VIEW_NAME' && $form_id == 'views_exposed_form') {
$form['#action'] = 'my/panel/path';
}
}
?>
#19
I think I came up with a more elegant solution that will work for an exposed filter block in any panels context.
See below:
<?phpfunction MODULENAME_form_views_exposed_form_alter(&$form, &$form_state) {
// check to see if this is a panel pane display
if(strpos($form_state['view']->display, 'panel_pane') !== FALSE) {
// if so, change the form action to reflect the panel's path
$form['#action'] = request_uri();
}
}
?>
merlin, do you think it would be possible to incorporate this into the logic of the exposed filter block itself somehow?
#20
Moving to the currently active version.
#21
When you add an exposed from block to a panel, it should contain an option: Inherit path. That does what this does, without the hack.
#22
Ah, OK. I wasn't aware that existed. Is it new?
#23
Greetings,
I'm having a problem with this. I have an exposed form in a panel pane, I've checked the option "Inherit path", but the exposed form is not inheriting the path. It is working correctly in non-panels pages. Is there another variable that may be the cause of this?
Thanks for any help you can provide.
Scott
**Update 9-4-11** I was able to correct this - the issue was caused by an oversight on my part.
#24
@scott859
We are having the same issue -- what was your oversight please?