Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
Certain search queries give me a lot (hundreds) of such errors:
Undefined index: #active in FacetapiFacetProcessor->processHierarchy() (line 1256 of /var/www/vhosts/123.nl/httpdocs/sites/all/modules/contrib/facetapi/plugins/facetapi/adapter.inc).
Notice: Undefined index: #markup in SearchApiWidgetsWidgetTinysortLinks->buildListItems() (regel 62 van /plugins/facetapi/widget_links.inc).
What could cause this? Have difficulty figuring this out.
Comment | File | Size | Author |
---|---|---|---|
#16 | facetapi-number_sign_prefixed_values-1398036-16.patch | 494 bytes | Leksat |
Comments
Comment #1
cpliakas CreditAttribution: cpliakas commentedHi morningtime.
Thanks for posting. I am changing this to a support request since there isn't enough information to determine whether it is a bug with Facet API. I also haven't seen this behavior using any of the core or contributed widgets, so I am thinking it isn't. Of course I have been wrong many, many times before.
What is the SearchApiWidgetsWidgetTinysortLinks class? All facet items are initialized with the variables you mentioned in the FacetapiFacetProcessor::initializeBuild() method, so there might be something going on in this widget that is altering the render array and producing the errors.
Thanks,
Chris
Comment #2
Anonymous (not verified) CreditAttribution: Anonymous commentedOk clear, here's some more information (while I'm still trying to figure out what really happens).
The bugs start with this
Notice: Undefined index: #active in FacetapiFacetProcessor->processHierarchy() (regel 1256 van /var/www/vhosts/123.nl/httpdocs/sites/all/modules/contrib/facetapi/plugins/facetapi/adapter.inc).
And then cascades into a dozen of the following errors:
Notice: Undefined index: #markup in SearchApiWidgetsWidgetTinysortLinks->buildListItems() (regel 62 van /var/www/vhosts/123.nl/httpdocs/sites/all/modules/local/search_api_widgets/plugins/facetapi/widget_links.inc).
Notice: Undefined index: #active in FacetapiFacetProcessor->processHierarchy() (regel 1256 van /var/www/vhosts/shopcircuit.nl/httpdocs/sites/all/modules/contrib/facetapi/plugins/facetapi/adapter.inc).
Notice: Undefined index: #markup in facetapi_sort_display() (regel 292 van /var/www/vhosts/123.nl/httpdocs/sites/all/modules/contrib/facetapi/plugins/facetapi/widget.inc).
It happens on search pages with specific filters, in my case for example only on brands=Lexmark. So I think there is some problem with retrieving facetlinks/filters. Will continue to debug this.
Comment #3
Anonymous (not verified) CreditAttribution: Anonymous commentedMore useful information I've found:
The problem happens when a certain facet $item has only:
As if the regular initializeBuild() is somehow skipped, forgetting #active, #html, etc. etc.
So where is this #count set? It only happens in Search API's
query_type_term.inc
on line 143:This seems to be part of a logic, where apparently an "empty" facet $item can slip through and get a #count value, but nothing else?
Comment #4
Anonymous (not verified) CreditAttribution: Anonymous commentedMore news:
When my code crashes, it seems the value of $filter is
#42 Black Return Program Print
The value starts with a "#" - could this be an issue?
Maybe the real problem is a bug in treating "#" signs in filter values?
Comment #5
Anonymous (not verified) CreditAttribution: Anonymous commentedI have a patch to "prevent" the bug from happening,
Fixes in plugins/facetapi/adapter.inc
and in processHIerarchy()
I couldn't create a real patch, your GIT branches seem strange, don't know what the RC1 is.
Comment #6
cpliakas CreditAttribution: cpliakas commentedGreat information, and thanks for your detailed debugging.
This might actually be a problem. Facet API deals with a lot of render arrays, so we could have a situation where the code thinks that value is a property and not a value when it is passed to drupal_render(). I am going to try to replicate this issue as I think it is the most plausible explanation. Again, excellent information and debugging.
How so? I am using the standard, documented branching techniques outlined on Drupal.org. The main line of development for the current release is the 7.x-1.x branch, whereas the other branches are targeted towards specific issues so we can have multiple lines of development for tougher problems. These topic branches follow the recommended
[issue-number]-[short-description]
nomenclature.Comment #7
cpliakas CreditAttribution: cpliakas commentedHm. Tested a few values that start with "#", and that doesn't seem to be the issue. Will follow up with a couple other leads you posted.
Comment #8
cpliakas CreditAttribution: cpliakas commentedStill can't replicate this issue. Anyone else having similar problems? If so, some debugging help would be appreciated.
Thanks,
Chris
Comment #9
cpliakas CreditAttribution: cpliakas commentedClosing since the discussion has tailed off and I still cannot reproduce this issue. Feel free to re-open if the problem persists and there is more information that can be provided.
Comment #10
randallknutson CreditAttribution: randallknutson commentedJust ran into this as well and debugged it further.
The bug appears to be in adapter.inc with the initializeBuild() function as speculated. Some of the values begin with a '#' which are filtered out of the for loop on line 1473 by the element_children() function. See;
If the build array looks like
Then the first item will be skipped in the loop resulting in:
Comment #11
cpliakas CreditAttribution: cpliakas commentedThanks for debugging! Bumping it back to the the 7.x-1.x version.
Comment #12
cpliakas CreditAttribution: cpliakas commentedI am still unable to replicate the issue. What I need to move this issue forward is detailed steps to reproduce. Postponing until someone can provide the steps.
Thanks,
Chris
Comment #13
Anonymous (not verified) CreditAttribution: Anonymous commentedTo reproduce, index values that start with #. Like "#hello" or "#101". The problem is the use of
element_children()
which does not read #hello.Comment #14
Rob_Feature CreditAttribution: Rob_Feature commentedI'm seeing this in an index field that does NOT start with "#". I'm indexing a simple "country" category field that has country names (Japan, China, etc). What I realized is that I'm using a hook_facet_items_alter()..removing that removes the errors.
My issue looks to be a problem with this hook from facetapi_bonus: #1995798: hook_facet_item_alter doesn't work as documented
I mention it in case anyone else is also using this hook and seeing these types of errors.
Comment #15
Anonymous (not verified) CreditAttribution: Anonymous commented@14, yes I also use that... facetapi_bonus.
Comment #16
Leksat CreditAttribution: Leksat commentedI also have an issue with #-prefixed values.
FacetapiQueryTypeInterface::build() defines that returning array must have indexed values as its keys. After that FacetapiFacetProcessor::initializeBuild() does
foreach (element_children($build) as $value) {
This excludes my #-prefixed values from the list.I had to quick-fix that replacing element_children() with array_keys(). But I'm no sure if it won't break something else.
Comment #17
molly_n CreditAttribution: molly_n commentedComment #18
cpliakas CreditAttribution: cpliakas commentedThanks for the explanation.
Technically how it works is that each backend's query type plugin (e.g. Apache Solr's date query type plugin) initializes the render array where the index value is set as each item's key. There is nothing stopping the query type plugins from adding properties to the render array (e.g. things starting with "#"), however I don't think any query type plugin does this.
To me the bug is worse than the small change that a plugin would need to add a property. I am going to do a quick scan in the community to see if any query type plugins are setting properties, and if not we can commit the patch in #16.
Thanks for sticking with this issue,
Chris
Comment #19
cpliakas CreditAttribution: cpliakas commentedFound the following query type plugins:
Note of them set properties, so I think the risk is very low that the patch will break anything. Marking as RTBC
Comment #22
cpliakas CreditAttribution: cpliakas commented