Since #1270890: provide a way to provide entity-related views fields went into Views, it is now possible to write back-end independent fields. Based on that it is pretty simple to implement a VBO field that works with the database backend, Search API (there is also an issue in the Search API issue queue #1123454: Integration with views bulk operations (vbo)) and so on.

I was taking a look at it and fixing the handler for normal entities would be pretty simple, as we could just reuse the views_handler_field_entity, which would also remove some code in the views_bulk_operations_handler_field_operations class. Then I realized that there is also support for entity revisions, which makes this approach complicated.

Directly extending the vbo handler from views_handler_field_entity would break the revisions, writing two separate handlers, one for the entities (whereas this extends field_entity handler) and one for revisions (extending the basic field handler), would duplicate much vbo specific code. So I decided to let the VBO handler stay pretty much the same as it was before and to add a specific field entity based handler. As this one can not extend from the vbo handler and the views entity field handler at the same time, some code is copied from the entity field handler.
I'm not really happy with this solution yet, but couldn't think of a better one. So waiting for your opinion.


Hi mh86,

is this patch still valid? You wrote you are not really happy with the current solution. So I wanted to ask if you have something new in the pipeline, before I try the patch.

I think using a generic is the right way to go. I'm using Search API with nodes and want to have VBO support as well. If you combine them you got a pretty slick user interface, not pretty but functional.

I think the generic entity handler support in Views needs to be extended to support revisions first.

Status:Needs review» Postponed

Based on #2.

I'll look into fixing the generic entity handler support in Views for revisions, before returning to this patch.

Regarding #2, is there an issue open for that for views?

Thanks, that issue should cover it.

I've decided that it's time I actually learned how this all works as I've reached the limit of hacking around :)

I think I may have been a little hasty in #7, so I don't believe that is the help we needed.

Status:Active» Needs review
new3.69 KB

Actually, in attempting to fix the rest of the problem in #1320942: Using field 'Content revision: Revert link (Revert link)' produces 'Warning: illegal offset type in node_access() (line 2857...' I discovered that the rest has been fixed in #1475640: Content Revision Delete and Revert links do not render. So on with this.

How about this patch or something similar.

It would probably be best for it to be renamed to views_bulk_operations_handler_field_entity_operations but for the sake of being able to see what has changed I've left that for now.

With the latest views and vbo dev I am using this patch and a patch for search_api and search api vbo is working properly for my small amount of testing :)

I have also tested a little with vbo and a node_revisions view and it is also working.

(adapted from the patch in the op)

Status:Needs review» Needs work

I don't see that working with revisions. You're passing $entity_id instead of $entity_vid as the checkbox value, which means that the correct revision can't get loaded.

Furthermore, seems to me Views still needs a bit of work to handle this properly. It's on my todo list, jut a matter of time.

new3.67 KB

A small modification on patch #9 to get the entity object and not the entity id to get work the function entity_extract_ids correctly.

Insted of $entity = $this->get_value($row); i'm using $entity = $row->entity;

Status:Needs work» Active

This might not be necessary since Views Rules provides generic entity handler support for Views. There's a subtle, yet profound, difference between them, in that View Rules adds support for performing views loops in Rules using its entity wrapper, whereas VBO exposes the results as a list. I'm sure someone else could offer a much better explanation, but the subtle difference is apparent when using them. As a user, what differentiates them is their methodologies and depth of integration.

I had originally followed this issue hoping to do exactly what I just recently did for Views Rules' #1650604-2: Example and/or video which uses Views XML Backend to do some really nice things with the Drupal Planet RSS feed.. locally. I don't know yet how to reconcile these new tools with VBO, but here's the exchange I had with bojanz just a few min ago:

... talking with another user
mitchell: have you seen yet?   (I say this with a ton of admiration to bojanz)
bojanz: mitchell: haven't seen it. I haven't really put effort in improving the rules-vbo bridge after the initial code was written, so I'm always happy to see efforts in that field
bojanz: though not sure views_rules makes it any less painful...
mitchell: bojanz: that's really cool
mitchell: bojanz: in fact..  it makes it pain-less
mitchell: *pain-free
bojanz: mitchell: interesting. Do you know if we can pull any improvements back into VBO? Or is the solution perhaps for VBO to stop doing its "load entities from VBO" completely?
mitchell: bojanz:  Re-use generic entity views table

Since it has been a while since the last message...

What's the current status of VBO + Search API? I am using Search API (with SOLR) and I would like to use VBO to build a "backend" interface to manage nodes.

Any help/info/suggestions would be really appreciated.


Good news!

This sandbox project works using the above patch and some code I remember seeing suggested elsewhere.

The only problem was that it is node centric, in a very minor way.

This code here specifically:

public function get_value($values, $field = NULL) {
// I'm not sure this is the best source for this but the name seemed
    // consistent.
return $values->entity->nid;

For crm_core, I just tweaked it to:

public function get_value($values, $field = NULL) {
// I'm not sure this is the best source for this but the name seemed
    // consistent.
return $values->entity->contact_id;

Theres probably some ways that this sandbox project could be improved to implement a more entity type generic solution.

Also wanted to say, Views Rules looks really neat, but doesn't seem to do what I need to do with VBO and search_api index views in this case. I will suggest it to the crm_core folks as I am sure they are interested in finding ways of creating 'smart groups' which Views Rules and taxonomy would be excellent for!

new3.69 KB

Patch from #11 didn't applied when using git command, breaking deploys with drush make. Here's a reroll that should work.

new3.74 KB

Changed one line to force patch above work with OG VBO actions:

= !empty($row->entity) ? $row->entity : $this->entities[$row_index];

Status:Active» Reviewed & tested by the community

The last patch it's working fine for me. Marking it as RTBC.

Issue summary:View changes
Status:Reviewed & tested by the community» Needs review
new3.04 KB
new2.85 KB

Updated the patch for the latest dev release (7.x-3.1+31-dev).

Sorry for the two patches. The smallest one is the good one.

Sorry, patch 18 was incomplete and broken. Here is a working patch.

#2 is still valid.
I rewrote the views get_result_entities() function for D8 to support revisions, that needs to be backported to D7.
There is an issue at #1802438: get_result_entities() Doesn't support revisions.

This is identical to patch 20, but uses get_value() to retrieve the row entity id. Safer.

Unfortunately this patch breaks processing of all pages. This is because:


if (issset($this->entities[$this->view->row_index])) {

This handler works based off of $view->row_index rather than $values passed into it. This seems like a strange thing for views to have done, but given that, the following code no longer works:

function views_bulk_operations_direct_adjust(&$selection, $vbo) {
// Adjust selection to select all rows across pages.
$view = views_get_view($vbo->view->name);
$view->display_handler->set_option('pager', array('type' => 'none', 'options' => array()));
// Unset every field except the VBO one (which holds the entity id).
  // That way the performance hit becomes much smaller, because there is no
  // chance of views_handler_field_field::post_execute() firing entity_load().
foreach ($view->field as $field_name => $field) {
    if (
$field_name != $vbo->options['id']) {
$results = array();
  foreach (
$view->result as $row_index => $result) {
$results[$row_index] = $vbo->get_value($result);
$selection = $results;

Firstly, $view->row_index will need updating on each loop. Secondly, $vbo->view is actually the original view which only has the first page of results, so once it gets passed there, the key in $this->entities no longer exists.

Also, $vbo->get_value() returns an entity, where as the selection expects an ID. The issues are similar in the queued selection.

I have attached an update patch that takes this into account. This now works perfectly and enables Search API to be used as a back end with the patch from #1123454: Integration with views bulk operations (vbo).

Correction - the above patch means Search API doesn't need anything doing to it to work, which is great as previously it was having to implement a method that had no real meaning just to make VBO work.

new2.35 KB
new5.95 KB

Ok, looked at this in the light of some of the comments about revisions and have re-worked it to support revisions. I have also put a patch up to views (#1802438: get_result_entities() Doesn't support revisions #12) which brings revision support into get_result_entities() which we make use of here, so this patch is dependant on that one.

i tried the patch with vbo 3.2. while i can configure the vbo field handler, it doesn't seem to execute for me.
what's also strange is, that the vbo field handler will disappear after adding another display to the view. at this point it seems to save the view, discard the missing vbo handlers. i can get those back registered by visiting the views overview page. unfortunately, then, the whole procedure just begins...

Status:Needs review» Needs work

Ah, pity to hear. So this is "Needs work" again, then?

Anyways, thank you still a lot for your work on this, pfournier and andrewbelcher!