When viewing any non-search pages (ApacheSolr search based) on our site we get the following error for every enabled facet:

Undefined index: my_term_facet in FacetapiAdapter->buildRealm() (line 1056 of sites/all/modules/contrib/facetapi/plugins/facetapi/adapter.inc).

In tracing through the code, the offending line is:

<?php
     
if (!$this->dependenciesPassed[$facet['name']]) {
        continue;
      }
?>

The problem is that the $this->dependeciesPassed array is only populated during a query call from the apachesolr module. So on non-search pages this array is empty.

We do have the option "Show facets on non-search pages. " disabled on the site.

So the issue appears to be that the module is still attempting to render facets even on non-search pages and thus running into an empty array. The offending call in this case is coming from facetapi_block_view().

So the question is what's the best way to solve this?

Should we just add a check to buildRealm() to make sure the array key exists or should we look at some modification to the block routines that call facetapi_build_realm() to make sure things have been initialized properly?

Files: 
CommentFileSizeAuthor
#6 facetapi-dependenciesPassed-undefined-index-1722898-6.patch598 bytesdas-peter
PASSED: [[SimpleTest]]: [MySQL] 528 pass(es).
[ View ]

Comments

I feel the same issue, but I think it's because I set the facet's to match my taxonomy terms.

Status:Active» Postponed (maintainer needs more info)

Shawn_Smiley,

Thanks for posting. Usually this issue means there is some larger implementation error, as the implementing module is trying to render facets before it initializes them. I have never encountered this error before, so I would appreciate some more details on your Apache Solr Search Integration setup so I can try to replicate.

Thanks for posting,
Chris

Software versions:

  • Drupal 7.14
  • apachesolr 7.x-1.0-rc3
  • facetapi 7.x-1.1
  • apachesolr_multisitesearch 7.x-1.0
  • apachesolr_media 7.x-1.0
  • references 7.x-2.0

We're using the ApacheSolr Search Pages interface to provide 3 pre-defined search pages (fixed filter on entity type) in addition to the default global site search (all provided by apachesolr).

The error mentioned in the original post occurs on every non-search page of the site and we get one error message for each enabled taxonomy or node reference facet. It also occurs on search pages if the apachesolr server is not reachable.

I'm going to try to setup a clean Drupal site and see if I can reproduce the error or trace down exactly where the conflict is originating from.

Status:Postponed (maintainer needs more info)» Active

Shawn_Smiley,

Thanks for the very detailed information. I will try to reproduce and give some debugging tips if I cannot.

Thanks,
Chris

Status:Active» Postponed (maintainer needs more info)

Just to report back, I have tried to replicate this bug and cannot seem to do so. Postponing until we can get some steps to reproduce on a clean install.

As a side note, there is an issue to create better error logging so that we can more easily track down the root cause of issues like this.

Sorry for your troubles,
Chris

Status:Postponed (maintainer needs more info)» Needs review
StatusFileSize
new598 bytes
PASSED: [[SimpleTest]]: [MySQL] 528 pass(es).
[ View ]

I have the same issue.

The scenario is following:
Search API using Search API Views and the whole thing is displayed using panels - this means the facet blocks are assigned to a panels region.
The Search API View has some input validators and processing the query is skipped if the prerequisites aren't met.
If the query isn't processed FacetapiAdapter::addActiveFilters() is not triggered - what means that FacetapiAdapter::$dependenciesPassed is empty.
However, as panels renders the facet block, regardless if the query was executed or not, FacetapiAdapter::buildRealm() is called, what finally throws the notice.

I suggest to use empty() to avoid the notice.

The defensive coding makes sense, however I am concerned that we are simply masking the underlying problem. Facet API expects that FacetapiAdapter::addActiveFilters() is called prior to any facets being rendered. I probably should have coded the FacetapiAdapter::buildRealm() to throw an error or something to enforce this, but that time has probably passed. Maybe I am misunderstanding the flow, but I see a lot of problems with facets not being initialized prior to rendering. The error is no fun, but if we hid it I fear other problems silently creeping in.

I absolutely understand your point, unfortunately I don't see a better way to get around this.
In fact I like that, if the query wasn't executed e.g. due to a failed validation, no more overhead is generated by building a "pointless" structure.
The only down side here is that panels doesn't care about the state of the query and renders the facet blocks as if everything was run.
Maybe I could configure a visibility rule in panels which checks if the query was run. But frankly speaking before I do that I'll create an own facetapi clone and use empty() in the if statement - just because I'm to freaking lazy to do this configuration ;)

How handle the normal blocks a case in which the search wasn't executed or at least FacetapiAdapter::addActiveFilters() wasn't called?

How handle the normal blocks a case in which the search wasn't executed or at least FacetapiAdapter::addActiveFilters() wasn't called?

Without panels, the blocks are "rendered" on every page, however there is a check in facetapi_block_view() that simply returns nothing prior to facetapi_build_realm() being called if things weren't initialized properly. The part that is confusing to me is that the FacetapiAdapter::addActiveFilters() invokes the facetapi_add_active_searcher() function. This is the API function that tells Facet API which searches were executed. If you take a look at the facetapi_check_block_visibility() function, which is called by facetapi_block_view(), you will see that it returns FALSE if the API function isn't called.

So to me that means a module must be calling facetapi_add_active_searcher() somewhere. Instead, it should call FacetapiAdapter::addActiveFilters() and all would be right with the world (hopefully).

Status:Needs review» Reviewed & tested by the community

So it doesn't look like Search API is calling this function. The whole panels logic is pretty complex and I am not confident that the root cause will be found anytime soon, so I am going to say the heck with it and commit the fix at #1722898-6: Undefined index warning in buildRealm() on non-search pages.. Marking as RTBC.

Status:Reviewed & tested by the community» Fixed

Thank you very much!
However, shall I open a follow-up issue in the Search API queue? I mean the comments #9 & #10 are very valuable and I think it would be good to check if Search API should enhance its Facet API integration.

It might be worth it to do so. I am trying to grok how this happens and replicate locally so I can undertand this use case better. I might just be misunderstanding the flow and making some bad assumptions, but it would be nice to at least have a place for continued discussions outside of this thread.

Thanks!
Chris

Thanks!

Status:Fixed» Closed (fixed)

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