Integration w/ Search API for nested field collections

I've seen some issues similar to this as well. A normal view allows you to fairly easily create a relationship back to the collection, and then add fields individually, or whatever.

When using SearchAPI, it seems very difficult to actually interact with the contents of the collection in a meaningful way through Views itself. I've had to do some funky stuff using the custom php field.

+1

I'm seeing this, and I think it belongs in the Search API as it does have field collection support.

Further to, it seems to index only the first occurrence if I have the same field on multiple collections. It just doesn't seem to iterate through the collections properly.

Does it really only index the first one, or is only the first one displayed in Views? Views display is entirely separate from indexing, and in fact even implemented in a different module, the Entity API. That for multi-valued relationships only the first element is retrieved was a deliberate restriction there, as implementation of other ways proved almost impossible. You can try to use the Views Field View module to circumvent this problem.

Regarding the related fields on the index's "Fields" tab always showing all fields added to any bundle on the entity type, and not restricting them to the proper bundle of the relationship: this problem is known, and also pretty much deliberate. Since the bundle information wasn't deemed reliable, we opted to rather show all fields than omit ones that would actually be present. I admit it's more confusing, but at least everything is there that way and no functionality lost ("only" UX). If we could find a reliable way to determine the bundles I'd be not opposed to fixing this, I think that numerous people have that problem, or rather annoyance.

However, regarding some fields not being there, that definitely shouldn't be the case. Maybe these fields don't integrate with the Entity API? Are they available for indexing when put directly on, e.g., nodes?

These are just normal textareas I'm seeing this on. The second instance of the field isn't filled with anything in the solr index, though it is there (ie: bundle1:field_text, bundle2:field_text - indexing only fills whichever was added first in the Search API fields selection page.)

I'll test it added to a node and let you know, but all my node fields, even if multiple, seem to have content.

Hi Drunken.

All elements are indexed with the following scenario: content type with a multivalued field of type "collection field". The view only display the first element informed on the field but facets are OK (just like you commented at #5).

The only bad thing I could find is that my taxonomy field inside the field collection is not listed at "index hirarchy" option on data alteration. May it be altered or is it intentional?

Regards,
Gilsberty

All elements are indexed with the following scenario: content type with a multivalued field of type "collection field". The view only display the first element informed on the field but facets are OK (just like you commented at #5).

OK, yes, this sounds like the known problem mentioned in #5.

The only bad thing I could find is that my taxonomy field inside the field collection is not listed at "index hirarchy" option on data alteration. May it be altered or is it intentional?

This is also a known problem, which sadly cannot really be fixed now. Fields of related entities are generally not available there.

I can confirm that I'm seeing very strange behavior with Search API for field collections. Just attempting to add a field to the index shows incorrect results.

For example, I have a field collection called "field_chairs" and a second field collection called "field_tables". When I add chairs as a field to index, there is no issue. However, when I try to add tables, the fields are displayed as "Chairs » Table Quantity" and "Chairs » Table Type".

I then create facets from these fields, and the Chairs block renders results, but the Tables block does not.

This appears to be a duplicate of #2489142: Add entity type-specific versions of the "Host entity" property for the field collection module which currently has a patch in the works.

Never mind, it appears the issue had to do with indexing Field Collections themselves, rather than nested field collections. This is indeed not a duplicate.

For example, I have a field collection called "field_chairs" and a second field collection called "field_tables". When I add chairs as a field to index, there is no issue. However, when I try to add tables, the fields are displayed as "Chairs » Table Quantity" and "Chairs » Table Type".

Could you provide more detailed steps for how you're doing this? Or maybe screenshots?

It's done simply by selecting a field collection entity from the "Add related fields" select dropdown at the bottom of the Fields tab. We regularly see options displayed in the Search API settings which are nonsensical.

For example, the following screenshots show a Field Collection called "Space Hours", and the only two fields on space hours are "weekday" and "hours." However when in Search API settings, it displays options such as "Space Hours > Table Type" and "Space Hours > Table Quantity", which are part of an entirely different Field Collection called "Tables". There is no connection between these two .

However, we actually have to select "Space Hours > Table Type" and "Space Hours > Table Quantity" for indexing, otherwise "table type" and "table quantity" are never searchable.

The first part is expected behavior. The same happens, e.g., when adding the fields of a node reference – no matter what the content type, the fields from all content types will be included. This is somewhere between hard and impossible to fix, due to technical restrictions.

The second one doesn't sound like it can be true. Can't you just index those fields for a different field collection (where they can actually be present)?
Indexing just these, you might get the option to add, e.g., a Views filter for them, but it won't ever find anything.

no matter what the content type, the fields from all content types will be included. This is somewhere between hard and impossible to fix, due to technical restrictions.

Ok, understood. Maybe worth editing the "Add related fields" message? Instead of:

"There are entities related to entities of this type. You can add their fields to the list above so they can be indexed too."

Can say:

"There are entities related to entities of this type. You can add their fields to the list above so they can be indexed too. Ensure the selected fields are associated with the entity, otherwise the field will not be indexed."

Can't you just index those fields for a different field collection (where they can actually be present)?

At the time I posted the message, "Tables > Table Quantity" and "Tables > Table Type" were not even options in the field list. The only choices related to Tables fields were "Space Hours > Table Quantity" and "Space Hours > Table Type".

Something must have changed between then and now, because I'm now seeing "Tables > Table Quantity" and "Tables > Table Type" as options. If I configure them as the other fields are configured, the values are indexed and rendered correctly.

OK, good to hear you could fix it!
I don't think that description text is the right place to point out this potentially puzzling behavior. But feel free to add it to the FAQ or the index settings documentation.

Have included a response in the FAQ.

https://www.drupal.org/docs/7/modules/search-api/getting-started/frequen...