Allow Views 3 Pane content type to expose filter as a block, and replace "inherit path" setting with "override path"

Just a quote from the code.

  /**
   * Block views use exposed widgets only if AJAX is set.
   */

Same issue here: in the "Exposed form" area, the "Exposed form in block" is visible only for page displays.
In other kind of display (i.e. default or Content pane) there is just the "Exposed form style" --> no way to activate/deactivate the block exposition.
This is not related to AJAX setting.

I got this issue after updating from an older 6.x-3.x-dev to a more recent 6.x-3.x-dev, and realized that the exposed block of a view disappeared from pages...

Yes, it's because that setting was actually invalid. Block and default displays have no path; exposed form in a block needs a path.

So, it will be no more possible to expose in a block the filters of a content pane view which uses the panel path ?

Should not has_path() be set to TRUE for view content panes which use the panel path ?

@#4 This 'bug' offered a great functionality in combination with Panels. I was using the exposed filters in a different panels column.
@#7 Sounds like a good solution to me

Ahem, using the same here. Am using the views 3 dev. The views-exposed filters in combination with panels is an attractive feature/bug.
It is working though, so not upgrading yet.

I made a patch with the suggestion from #7
Merlin i hope you can live with this patch :)

Changed the patch, changing the has_path() method caused another error (path not set). So this might be better

It worked for me.

+++ views/plugins/views_plugin_display.inc	2011-06-14 16:44:17.000000000 +0200
@@ -1091,7 +1091,7 @@ class views_plugin_display extends views
+    if ($this->has_path() || $this->get_option('inherit_panels_path')) {

Can't the panels display override the has_path method?

Powered by Dreditor.

If the has_path method is overridden then the validate function needs to be overridden as well (and get_path?).
See line 2319

if ($this->has_path() && !$this->get_option('path')) {
 $errors[] = t('Display "@display" uses a path but the path is undefined.', array('@display' => $this->display->display_title));
}

@dereine: do you intend that Panels module has to be patched to restore the correct behaviour ?

@robbertnl

The great advantage of OOP here is that you can inherit /override behaviour. So there is no reason to hardcode something special specific in it.

I agree patching panels is the most logical place.
I was too fast with my patch, i might make a new one for panels if i have some spare time

@robbertnl: yes please, provide a patch to panels so that it can be commited.

I temporary resolved by adding the following code:

  function uses_exposed_form_in_block() { return TRUE; }  

in the following file:
...\sites\all\modules\ctools\views_content\plugins\views\views_content_plugin_display_panel_pane.inc

So it seems more related to CTools than Panels...

+1 for exposed forms in block and default views.
I used this "bug" with panels all the time...

#20 doesn't fully solve this issue.
I still needed a way to *override* the panel and views path, instead of only inherit/not-inherit.
Since the view (and therefore the view pane) doesn't have a path at all, i need to be able to explicitly set the exposed filter path.

This patch not only implements uses_exposed_form_in_block() as in #20, but also changes views_content.module's inherit_path setting to path_override, similar to the way it's implemented in views_panes.inc content type.

Sorry, this should is against Ctools 6.x

Patch #22 works for me.

Majdi - this is tangential to the issue addressed by the patch.

As far as I know, an exposed filter block does not support ajax.
So, there's no reason to expect that combining an unsupported feature with panels will somehow add ajax support.
Your issue should be reported separately, and possibly against Views, not Ctools.

For the patch in #22, at this part :

+    '#default_value' => $form_state['conf']['path_override'],
   );
 }

It should say:

+    '#default_value' => $form_state['conf']['path_override'],
   );
  return $form;
 }

And, I'm not sure if this is because of another patch a coworker of mine implemented, but this part of the patch was redundant for me (that function already existed further down in the code):

Index: views_content/plugins/views/views_content_plugin_display_panel_pane.inc
===================================================================
--- views_content/plugins/views/views_content_plugin_display_panel_pane.inc	(revision 184)
+++ views_content/plugins/views/views_content_plugin_display_panel_pane.inc	(working copy)
@@ -12,6 +12,10 @@
   var $panel_pane_display = TRUE;
   var $has_pane_conf = NULL;
 
+  function uses_exposed_form_in_block() {
+    return TRUE;
+  }
+
   function option_definition() {
     $options = parent::option_definition();

But thanks for the patch, it worked for me and is very useful for using an exposed form for a 'search' page, and using a view pane on another panel page as a results page.

Should this be bumped to D7? Think that's where most of the development is happening for CTools now (if not D8).

Drupal 6 is no longer supported, closing.