Closed (fixed)
Project:
Search API
Version:
8.x-1.x-dev
Component:
Plugins
Priority:
Normal
Category:
Bug report
Assigned:
Unassigned
Reporter:
Created:
15 May 2016 at 22:42 UTC
Updated:
21 Jun 2016 at 11:54 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #2
bc commentedI've created a stopgap patch to fix things in the meantime. I made Drupal\search_api\Plugin\search_api\datasource\ContentEntity::hasBundles public, and then I modified buildOptionsForm to only include the bare entity's view modes if it doesn't have any bundles.
SearchApiRow::render will check if
$this->options['view_modes'][$datasource_id][$bundle]is set, but $bundle in this case is named in a different way than I created it above. There's a convention for creating a fake bundle name.. maybe I could use that here & the render method can expect that. What happens if an entity with bundles has a name that collides with the fake bundle name? Maybe we shoudl test for hasBundles here -- that would be more direct :)Comment #3
drunken monkeyThanks for reporting this problem! Seems we didn't think about that.
How about this for a solution? Doesn't seem necessary to have any other parts of the code know about the peculiars of the entity/bundle system.
Or does this not completely solve the problem, would we maybe still need to adapt
SearchApiRow?Testing proper integration for this in the Views UI would be great, but I fear there is no simple way to do that, so it would be much too much effort. (If you want to try it, though, go ahead – would be great to have.)
However, at least we can easily test this on the low level, to see whether the datasource behaves correctly.
Comment #4
joachim commentedWeird. I'm using a custom entity type which has no bundles defined, and I'm able to select a view mode for it.
Comment #5
borisson_The new test looks great.
Comment #8
drunken monkeySeems I forgot to set the "tests only" patch to be tested – but verified that it fails locally now.
Thanks for reviewing!
Committed.