Come together with the global Drupal community in Rotterdam, 28 Sept – 1 Oct 2026. Sessions, contribution, connection, and Early Bird savings until 8 June.Environment
Search API v7.x-1.0-rc1
Search API Database v7.x-1.0-beta2
Facet API v7.x-1.0-beta8
Problem/Motivation
Unable to index all content. Certain content returns a fatal error as it attempts to mathematically add an array to an integer.
Proposed resolution
Validate the value of the variable $value to ensure an array is not being added to an integer. I haven't retraced the data flow to figure out why the var type is "array" at that point in the logic. The attached patch will perform a simple numeric check.
Remaining tasks
Please test the patch or trace the logic back to see if there is a better fix higher up in the processing.
| Comment | File | Size | Author |
|---|---|---|---|
| search-api-db-beta2_index-operand-error.patch | 391 bytes | KeyboardCowboy |
Comments
Comment #1
drunken monkeyThe patch doesn't work, it executes the same code for both alternatives.
Also, it'd be great if you could find out more about the cause, at least which fields and settings trigger the error. I think we shouldn't treat symptoms, but remove the error's cause if possible.
Also, please check whether re-saving the index's „Fields“ form solves the problem. It seems that at some point in the past DB server settings weren't correctly updated.
Comment #2
jax commentedHaving the same issue, it's caused by having a multivalued term reference.
$value, $type and $original_type in SearchApiDbService->convert() are then:
array
0 => string '8'
1 => string '9'
string 'integer'
string 'list<taxonomy_term>'
So it fails the search_api_is_list_type() calls since type is integer.
Comment #3
jax commentedI'm guessing that somewhere original_type list<taxonomy_term> is converted to type integer instead of list<integer>.
Comment #4
jax commentedThe issue is when you first create a taxonomy term reference field with a cardinality of 1, then go to the search api fields configuration and check that field to be indexed. Then you change the cardinality of the field and you will get this error because search_api saved the type of the field as integer instead of list<integer>.
The solution is to resave the fields configuration in the search api configuration after you change the cardinality of a field.
So this is more a search_api issue. It should be able to react to field configuration changes.
Comment #5
drunken monkeyMoving to right queue.
But as you said, right now re-saving the Fields form is a good workaround. I'm not really sure what a good more or less generic way to react to such changes would be. I'd rather not employ a Fields-specific solution.
Comment #6
drunken monkeyPS: Would you happen to know or could test whether such a change also messes up Search API-based views with that term field?
Comment #7
jason.fisher commentedI believe my issue at https://drupal.org/node/2115915 might be related. Somewhere my list_text is becoming list and then string. It is a dropdown field with a cardinality of 1, but I think I still need it to be a list so the Views UI allows a dropdown multi-select on the filter?
Comment #8
drunken monkeyThis has (hopefully) been fixed long ago by #1694832: React properly to Field API field changes.
And no, jason.fisher, that's completely unrelated.