Just spotted that there is actually a bug in the way we load entities when the " Additional access checks on result entities" option is enabled for a view. This is the code in question:
if (!empty($this->options['entity_access']) && ($entity_type = $this->index->getEntityType())) {
$entity = entity_load($entity_type, array($id));
if (!entity_access('view', $entity_type, $entity[$id])) {
continue;
}
}
$id
here is the datasource's item ID for the item – but that doesn't need to be the same as the item's entity ID. E.g., if you have a multilingual index created through the Search API ET module, the item IDs also contain the items' language codes, thus making them invalid when used as entity IDs. So, in such cases, the above code won't work and all items would be rejected, an empty result displayed.
Comment | File | Size | Author |
---|---|---|---|
#8 | 2412895-8--views_entity_access_check.patch | 1.32 KB | drunken monkey |
|
Comments
Comment #1
drunken monkeyPatch attached.
Comment #2
joelpittetI think this fixed a WSOD that I traced back to search_api_index which I found from this: http://drupal.stackexchange.com/a/15649/3998
Comment #3
drunken monkeyGreat to hear, thanks for testing!
Committed.
Comment #5
drunken monkeyAh, almost forgot, we should of course also include this in the D8 version. (Just copying it verbatim should be enough, since that part is currently commented out (for some reason) anyway.)
Comment #6
drunken monkeyComment #7
dragos-dumi CreditAttribution: dragos-dumi commentedPorted the patch for 8.x-1.x branch.
Comment #8
drunken monkeyOK, "verbatim" was a bit optimistic of me, sorry about that. Actually, those methods have changed a bit (and there is now an
access()
method on entities, so that line was actually correct already).Still, thanks for your help!
Also, seeing the code again, let's try enabling it? Does it blow up horribly, or why was it commented out?
Comment #9
drunken monkeyHm, seems to be fine. So, committed.
Thanks again for your help!