Undefined indexes #active, #markup, etc.

Hi 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

Great information, and thanks for your detailed debugging.

The value starts with a "#" - could this be an issue?

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.

I couldn't create a real patch, your GIT branches seem strange

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.

Hm. 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.

Still can't replicate this issue. Anyone else having similar problems? If so, some debugging help would be appreciated.

Thanks,
Chris

Closing 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.

Just 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;

    // Iterates over the render array and merges in defaults.
    foreach (element_children($build) as $value) {
      $item_defaults = array(
        '#markup' => $value,
        '#indexed_value' => $value,
        '#active' => $adapter->itemActive($this->facet['name'], $value),
      );
      $build[$value] = array_merge($defaults, $item_defaults, $build[$value]);
    }

    return $build;
  }

If the build array looks like

$build = array(
  '#101' => array('count' => 1),
 '102' => array('count' => 1),
);

Then the first item will be skipped in the loop resulting in:

$build = array(
  '#101' => array('count' => 1),
 '102' => array(
    '#count' => 1,
    '#markup' => '',
    '#indexed_value' => '',
    '#active' => '',
  ),
);

Thanks for debugging! Bumping it back to the the 7.x-1.x version.

I 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

I'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.

I 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.

Thanks 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

Found the following query type plugins:

• http://cgit.drupalcode.org/search_api/tree/contrib/search_api_facetapi/p...
• http://cgit.drupalcode.org/search_api/tree/contrib/search_api_facetapi/p...
• http://cgit.drupalcode.org/apachesolr/tree/plugins/facetapi/query_type_d...
• http://cgit.drupalcode.org/apachesolr/tree/plugins/facetapi/query_type_g...
• http://cgit.drupalcode.org/apachesolr/tree/plugins/facetapi/query_type_n...
• http://cgit.drupalcode.org/apachesolr/tree/plugins/facetapi/query_type_t...
• http://cgit.drupalcode.org/search_facetapi/tree/plugins/facetapi/query_t...
• http://cgit.drupalcode.org/search_facetapi/tree/plugins/facetapi/query_t...

Note of them set properties, so I think the risk is very low that the patch will break anything. Marking as RTBC