VBO fields are not addable anymore for search API indexes

Can confirm this exists in 8.x branch.

I have a view that searches through search api index and returns results. A trade off to replacing the default content search in Drupal was giving up the built in node bulk operation checkboxes.

I installed VBO to see if I could get that back. I know in previous versions, you could add VBO to things other than content (orders, for example) so I thought I could do that here.

When I tried to add the Views Bulk Operation field to the view, the modal did not go away. Browser console errors stacked up (500 error). When I refreshed the browser I got a fatal error about no entity type being found for the field I just added (I never got a chance to configure it).

The only remedy here was running a drush cim to restore state (disable module), and clear cache. Then remove the "Broken/missing handler" field from my view.

Is there a way to get this to work?

I don't think there's a solution to this. We execute actions on entities, if there's no entity type, but only fields provided by a 3-rd party or some db table, we don't have entities to execute actions on. The only thing I can do is disabling the field if the view doesn't have the entity type param.

It's working on one of my projects on D7 version, I'll investigate if this can also be achieved on D8.

Unfortunately, there are 2 major blockers caused by the search API:

1. The views Drupal\views\Plugin\views\HandlerBase::getEntityType() method will throw an exception, because search_api index $views_data['table'] doesn't contain 'entity type' element.
2. The views Drupal\views\Plugin\views\field\FieldPluginBase::getEntity(ResultRow $values) method will fail, because for some reason search_api stores result entities in $values->_object->entity instead of $values->_entity as in normal situation ($values->_entity is NULL).

Both could be solved from VBO side by overriding the many class methods, if it wasn't for the fact that a search index can store different entity types - in such a situation the getEntityType() method is useless.

It was a pain, and I think that also search_api should be adapted a bit to views standards, but my new code seems to be working fine.

I created a feature branch for testing (2566879-search-api), it has a lot of changes and overrides of core views code so I'm not merging it to the 8.x-1.x yet.

Please anyone that has a bit time review, hopefully there's no performance drop in case of standard entity views.

Cheers,
Graber

Just a general guideline: let's not put specific search api code in the code base, and more work on the problem of allowing generic functionality for any contrib, or a hook to enable a integration module to do this.

I've not looked too much into the code in both 7.x or 8.x cases and letting Graber, tackle 8.x stuff generally. Just want to keep people on the same page so we don't have contrib support code mixing with the general functionality.

Good point @joelpitet, we don't want code quality and / or performance drop resulting from placing code that should be somewhere else.

I've created an API request issue: Provide API for contrib modules

When the API is ready and the problem will still require attention, this should be a search_api feature request issue. The integration will be possible in search_api itself or any contrib module.

I'll leave the issue feature branch for some time, maybe someone will find it usefull before the issue is solved the right way.