Currently, you cannot place a Facet API block above the actual search results in Panels.
Also, the blocks are listed under "Miscellaneous".

This, in conjunction with #1669908: hook_ctools_content_subtype_alter() does not run early enough, fixes this.

That Panels patch does not need to hold up this patch.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

tim.plunkett’s picture

Status: Active » Needs review
FileSize
586 bytes

See attached.

EclipseGc’s picture

+1000000000 to seeing this go in.

cpliakas’s picture

Status: Needs review » Reviewed & tested by the community

Haha. Well then, I guess it is important :-) Doesn't seem to break anything, so I will take you guys at your word that this is a good addition.

Thanks for the contribution,
Chris

cpliakas’s picture

Status: Reviewed & tested by the community » Fixed

Committed to the 7.x versions of Facet API.

Congrats on becoming the 30th code contributor to Facet API!

Status: Fixed » Closed (fixed)

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

liquidcms’s picture

hey, sorry to re-open; possibly i am not trying to do the same thing?

i have:
- search api (latest -dev)
--- seach api db
--- search api facets
- ctools (latest -dev)
- views integration
- facets api

i have set up a View to use as search results with search api; works great.

trying to add facets. if i add one of my facet blocks to a region through std drupal block admin; it works fine.

if i add this same block (from the Panels Facet API section) into a pane on a custom panel page (custom page created using Page Manager Existing Pages) - i get nothing

is this what this issue is referring to? have i missed something?

liquidcms’s picture

another interesting thing with this is i couldn't get the exposed filters block from search api to work inside a pane either so i added this code as custom pane content:

$block = block_load('views', '-exp-search_test_2-page_1');
print render(_block_get_renderable_array(_block_render_blocks(array($block))));

but this approach did not work for facet blocks.

azinck’s picture

I'm still seeing the same behavior as liquidcms describes above, using the latest devs of all modules involved. I'm looking into the problem and will follow up with more details.

azinck’s picture

I'm trying to add facets to pages that otherwise don't have a solr query being executed on them. I want facets to display on a page at path 'data' and link to a listing page at path 'data/search'. Everything works perfectly if I add Views facet blocks or Facet API blocks via the core block module. I can use a Views facet block to create the solr query (I hide this Views facet block via the setting provided in the view display) and use it to set the desired link path (again, this is a setting provided via the views facet block display). I then add the Facet API blocks I want which leverage the query created by the Views facet block. These Facet API blocks display their facets accordingly, and the facets link to 'data/search' as specified by the setting in my Views facet block. The problems arise when I try to do this with Panels:

If I add a Views Facet Block to a panel *without* having the "Views content panes" module enabled I get the following error when I try to save the panel:

    Warning: strlen() expects parameter 1 to be string, array given in drupal_validate_utf8() (line 1573 of C:\Documents and Settings\ZinckA\fas\docroot\includes\bootstrap.inc).
    Notice: Array to string conversion in filter_xss() (line 1434 of C:\Documents and Settings\ZinckA\fas\docroot\includes\common.inc).
    Warning: Invalid argument supplied for foreach() in element_children() (line 6370 of C:\Documents and Settings\ZinckA\fas\docroot\includes\common.inc).
    Warning: Illegal string offset '#children' in drupal_render() (line 5837 of C:\Documents and Settings\ZinckA\fas\docroot\includes\common.inc).
    Warning: Illegal string offset '#children' in drupal_render() (line 5847 of C:\Documents and Settings\ZinckA\fas\docroot\includes\common.inc).
    Warning: Illegal string offset '#children' in drupal_render() (line 5885 of C:\Documents and Settings\ZinckA\fas\docroot\includes\common.inc).
    Warning: Illegal string offset '#printed' in drupal_render() (line 5892 of C:\Documents and Settings\ZinckA\fas\docroot\includes\common.inc).
    Warning: strlen() expects parameter 1 to be string, array given in drupal_validate_utf8() (line 1573 of C:\Documents and Settings\ZinckA\fas\docroot\includes\bootstrap.inc).
    Recoverable fatal error: Object of class SearchApiFacetapiAdapter could not be converted to string in filter_xss() (line 1434 of C:\Documents and Settings\ZinckA\fas\docroot\includes\common.inc).

If I attempt to add the same Views Facet Block to a panel *with* the "Views content panes" module enabled then I'm able to save, but when I view the resulting panel nothing is output for the Views facet block (no, I don't have it configured to be "hidden" in this case) and I get the following notice at the top of the page:

Notice: Undefined index: theme in views_plugin->theme_functions() (line 529 of C:\Documents and Settings\ZinckA\fas\docroot\sites\all\modules\contrib\views\includes\plugins.inc).

In the second case, above, when I have the "Views content panes" module enabled, I can add Facet API blocks to the page along with the Views Facet Blocks. The Views Facet Blocks, despite not displaying anything, must be creating a solr query since the Facet API blocks do display the appropriate facets. The main problem (beyond the error notice) is that the Facet API blocks are not correctly deriving their path from the Views Facet Block (I want them to link to `data/search`).

I'm continuing to look into this but wanted to post a full description of my symptoms as I'm seeing them now. I'm also not entirely sure if the fault lies with Facet API or Search API (or Panels...or Ctools...or Views...).

azinck’s picture

Have made a little progress. See my post in the CTools issue queue for more details: #1925046: Inconsistency in how views_content module creates executes/renders views as compared to core block module

azinck’s picture

The problem I'm having seems to be caused by bugs in Search API's Views integration. Here's the issue I've posted in the Search API queue along with a preliminary patch: #1925114: Improve Search API Views Facet Blocks integration with Panels (and other things too)

Jon Pugh’s picture

Issue summary: View changes
Status: Closed (fixed) » Active

Re-opening for Mini Panels.

Seems to have the same problem that individual blocks used to have.

Reproduce by:

  1. Create a mini panel including facet API blocks.
  2. Place the mini panel "above" your search results view.
  3. View the panel page, noting that the mini panel doesn't show up.
  4. Move the mini panel "below" your search results view.
  5. View the panel page, noting that it now appears!

Not sure how to fix this...

azinck’s picture

@Jon Pugh:

Seems like mini panels in _panels_mini_panels_mini_content_type_content_type() should inspect its contents to see if it contains any panes that contain the 'render last' attribute. If so, it should set its own 'render last' attribute to TRUE.

mitsuroseba’s picture

Reroll for panels

nijk’s picture

#14 worked for me on Panels 7.x-3.4

sgurlt’s picture

Status: Active » Reviewed & tested by the community

#14 worked for me as well, it allowed me to place a mini panel containing facets in my left sidebar of my panel page.

Status: Reviewed & tested by the community » Needs work

The last submitted patch, 14: panels-add-render-last-for-minipanel-1669918-14.patch, failed testing.

DamienMcKenna’s picture

The patch should check the status of the panes included in the mini panel before assigning "render last". Also, should this issue be moved to the Panels issue queue or should another issue be opened just for this bug?

NWOM’s picture

Shouldn't a new thread be made for Panels for #14? Since it won't be committed while in this thread. I will leave as is for now, in case this is intentional.

azinck’s picture

Status: Needs work » Closed (fixed)

I've taken out a new issue in the Panels queue for the Mini Panels problem and posted a patch over there: #2577141: 'render last' and 'render first' attributes on panes in mini panel should trickle up to parent panel

Re-closing this issue.