Somewhere between beta3 and rc1 the ability to put exposed forms into their own block's disappeared for content panes.

To reproduce:
1) Install clean site, enable Views and Content panes
2) Create a new page display. Note the option "Exposed form in block" being available.
3) Create a new pane (or context) display. Note the same option now missing.
4) Profit!

I tried with both stable and -dev of ctools aswell.

Assigning directly to dereine as I can't figure it out and it's a D7 issue.
If I can figure git-bisect out I'll pin-point the commit later.



Letharion’s picture

Using Drupal 7.4.

dawehner’s picture

Project:Views» Chaos tool suite (ctools)
Version:7.x-3.x-dev» 7.x-1.x-dev
Component:exposed filters» Views Content

This seems to be a ctools issue.

aidanlis’s picture

Subscribe (Same applies in D6)

merlinofchaos’s picture

Status:Active» Fixed

Committed a fix that allows content panes to have the exposed form in a block back.

There may be some side effects, tho; need to see how this works for people.

merlinofchaos’s picture

Status:Fixed» Active

This patch has been reverted due to side effects.

merlinofchaos’s picture

Status:Active» Fixed

Ok, I've made commits to both Views and CTools that will fix this. Views gained a new method to control whether there can be exposed form in block, and CTools now uses it.

pepperoni13’s picture

Status:Fixed» Needs review

I updated Views 7.x-3.0-rc1 and Chaos tool suite 7.x-1.0-beta1, I am using Drupal 7.2.

got this error


'Exception: SQLSTATE[23000]: Integrity constraint violation: 1052 Column \'uid\' in field list is ambiguous'

in views_plugin_query_default->execute() (line 1380 of C:\xampp2\htdocs\july18\sites\all\modules\views\plugins\

'Exception: SQLSTATE[23000]: Integrity constraint violation: 1052 Column \'uid\' in field list is ambiguous'

in views_plugin_query_default->execute() (line 1380 of C:\xampp2\htdocs\july18\sites\all\modules\views\plugins\

then I added:

function uses_exposed_form_in_block() {
// We'll always allow the exposed form in a block, regardless of path.
return TRUE;
to and still have error message.

I don't know if it has something to do with the views update or not. I hope you can shed some light on this. I know its not something I wrote as I have never wrote a line of code for this site.

I just don't understand why it worked before I upgraded the modules and now it doesn't!?

merlinofchaos’s picture

Status:Needs review» Fixed

I don't see how the errors you describe are related to this issue.

Also please read the link about what the status means before changing status on an issue.

Returning to previous state.

capellic’s picture

I've tested and it works.

I downloaded the DEV versions of ctools and views on July 21. No update.php required.


Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

jjclint’s picture

I'm actually still having this problem with the latest dev version. Inherit path is on and I still get redirected to the homepage.

RCC_Adam’s picture

new7.68 KB

merlinofchaos - Just wondering if these changes will be rolled back to the 6.x branches of both Views and CTools to "re-enable" the "exposed form in block" functionality for content panes. I thought maybe this had been done and switched to the latest 6.x dev releases for both but the option is still missing on the views ui.

FYI: works for "page" display types, but not "content pane" display types.

RCC_Adam’s picture

Forget it. I figured it out. I feel shame... :(

vinoth.3v’s picture

Status:Closed (fixed)» Active

same here (exp. form missing) with latest ctools version 7.x-1.2, views 7.x-3.5, panels 7.x-3.3
any idea?

queenvictoria’s picture

I concur. Looks like its gone from latest and dev versions. Has it been removed? Can anyone spot the patch that was applied in July last year?

queenvictoria’s picture

Looks like its been moved into a separate feature. IE.

  1. Create a views page
  2. Expose the filter
  3. Enable the `Views content panes` module (part of CTools)
  4. In panels find both the view and the filter in the new `Views` section
justinchev’s picture

I've written a little post about getting this working (to remind myself of the steps mostly).

The jist is that you need to create your view using 'Content pane' display type, and set the pane settings to 'using panel path = yes'.

  • merlinofchaos committed 33d7294 on 8.x-2.x
    Issue #1206230: Allow content pane displays to have exposed form in...
  • merlinofchaos committed 8f0801e on 8.x-2.x
    Revert "Issue #1206230: Allow content pane displays to have exposed form...
  • merlinofchaos committed 880f0db on 8.x-2.x
    Issue #1206230: Really allow exposed form in block. Requires matching...
bburg’s picture

Issue summary:View changes

I'm running into this, but only with fulltext search forms from Search API. Standard view exposed forms are rendering as expected. I am attempting to debug this.

bburg’s picture

So my issue in #19 was that I had set the view's content pane display's "Allow settings" option under the pane settings for "Use exposed widgets form as pane configuration" to be enabled. This meant that view->display_handler->displays_exposed() in render_exposed_form() returned false (which it takes the inverse of causing the function to return an empty string instead of the rendered form). Presumably this is done with the notion that the content pane settings will provide options to determine whether exposed forms are displayed. For me, I never get such an options form.

a.milkovsky’s picture

@bburg, thank you for pointing "Use exposed widgets form as pane configuration" in #20