PHP Fatal error: Cannot use assign-op operators with overloaded objects nor string offsets in processor.inc on line 295

Thanks for reporting this! However, the bug seems to be in an entirely different area: it seems Search API is somehow trying to index the whole body field, instead of just the value, which shouldn't be possible.
Are you using the latest version of Search API? On the index's "Fields" tab, what is the machine name of the indexed body field (or all body fields that have "Indexed" checked)?
Does this happen for all items, or just for some/one? Could you find out the value of $data before $this->preprocessIndexItems($data); in the index class (ca. line 499 of includes/index_entity.inc), or at least the relevant sub-key(s) of it?

Can this be committed? I encountered the same issue with latest, 7.x-1.15 Search API and the patch solved it for me.

Can this be committed?

No, as said in #1, it cannot. It's entirely the wrong place to fix this.
Please answer my questions in #1 to help resolve this.
Also, please explain your basic setup, especially the processors you're using.

Hi, Thanks for the module.

I confirm that this patch solve the problem for me too, using search_api 7.12.
I started having this problem when I activated wysiwyg on one of the indexed fields. I hope this can lead to a proper solution.

Regenerated the patch for version 7.x-1.20.

I started having this problem when I activated wysiwyg on one of the indexed fields. I hope this can lead to a proper solution.

That still leaves my other questions unanswered – and also, "search_api 7.12" is no module version. Do you mean "7.x-1.12"? Or 1.20, for which you've created the patch? (Which seems to have been unnecessary in any case, by the way.)

Hi @drunken monkey, sorry for the mistake. it is search_api 7.x-1.20 (now, at the time of comment #4 was 7.x-1.12). The issue is the same, you activate HTML for the field and search_api give you the fatal error because of the data structure. It is easy to reproduce.

OK, good to know.
However, I still need answers to my questions in #1 for helping you.
Also, what are the steps to reproduce? Just index the body field and then switch on WYSIWYG for it? Steps from a clean install would be best.

exactly what you you just said:

• you add a field "my_field" to a content type as text
• you index the CT
• you change the "my_field" switching on the WYSIWYG
• you relaunch the index

the result is the error reported here and the patch solve it.

Couldn't reproduce this.
Using the default node index (which of course has the body indexed) I …

1. Installed the WYSIWYG module and set it up for the "Filtered HTML" format. (I only enabled the B, I and U buttons – can you reproduce with just those, or is it maybe one specific button that causes this?)
2. Edited a node, changing format to "Filtered HTML" and adding some formatting with WYSIWYG.
3. Re-indexing, with all processors enabled.
4. Indexing works fine, no problems.

As per #1, it would be helpful to know the value of $data before processing.

I am closing this issue because information was requested over a year ago, but no new information has been provided since. Please reopen this issue with the requested information if you think that this issue is still relevant.