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.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Anonymous’s picture

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.

bojanz’s picture

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

bojanz’s picture

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.

rooby’s picture

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

bojanz’s picture

rooby’s picture

Thanks, that issue should cover it.

rooby’s picture

rooby’s picture

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.

rooby’s picture

Status: Active » Needs review
FileSize
3.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)

bojanz’s picture

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.

akozma’s picture

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;

mitchell’s picture

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 https://drupal.org/project/views_rules 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: https://drupal.org/node/1334374  Re-use generic entity views table
Anonymous’s picture

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.

Thanks!

rerooting’s picture

Good news!

http://drupal.org/sandbox/AlexArnaud/1910528

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!

David Hernández’s picture

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

f5.andrii’s picture

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

  $entity = !empty($row->entity) ? $row->entity : $this->entities[$row_index];
David Hernández’s picture

Status: Active » Reviewed & tested by the community

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

pfournier’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Needs review
FileSize
3.04 KB
2.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.

pfournier’s picture

pfournier’s picture

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

bojanz’s picture

#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.

pfournier’s picture

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

andrewbelcher’s picture

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

views_handler_field_entity::get_value()

    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->set_exposed_input($vbo->view->get_exposed_input());
  $view->set_arguments($vbo->view->args);
  $view->set_display($vbo->view->current_display);
  $view->display_handler->set_option('pager', array('type' => 'none', 'options' => array()));
  $view->build();
  // 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']) {
      unset($view->field[$field_name]);
    }
  }

  $view->execute($vbo->view->current_display);
  $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).

andrewbelcher’s picture

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.

andrewbelcher’s picture

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.

dasjo’s picture

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...

drunken monkey’s picture

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!

botris’s picture

I can confirm the patch from #25 to work with Search Api 7.x-1.11 & VBO 7.x-3.2

gilgabar’s picture

I also had success with the patch in #25. I am now able to add a VBO field handler to a view of a Search API index of my custom entity type. I was unable to reproduce the issue reported in #26.

laszlo.csongor’s picture

I can confirm that patch from #25 is working with Search Api 7.x-1.13 & VBO 7.x-3.2, however there is an issue when using the patched VBO 7.x-3.2 together with Flag 7.x-3.5 (https://www.drupal.org/project/flag).

Any suggestions on how can I solve this?

valthebald’s picture

Status: Needs work » Reviewed & tested by the community

I think we should move this to RTBC, and maybe address issue from #30 in a separate issue (not sure if it will belong to VBO or to flag)

kiss.jozsef’s picture

I can confirm too that patch from #25 is working with Search Api 7.x-1.13 & VBO 7.x-3.2 but it breaks the Load a list of entity objects from a VBO View and Load a list of entity ids from a VBO View rules actions .
In views_bulk_operations_action_load_list() the foreach runs only once the entity_metadata_wrapper breaks it, and in the
$vbo->get_value($result) function the $this->view->row_index is empty.

damien_vancouver’s picture

Another confirmation that #25 works against VBO 7.x-3.2. After application and cache clearing I'm able to add a Bulk Operations field handler and everything is working as expected. I had no other problems, but am using only the "pass arguments to a page" handler.

In order to get it working I needed not only this patch but also the code from #35 at #1123454: Integration with views bulk operations (vbo) (also here: https://www.drupal.org/node/1591360)

Over on the Search_API queue, #1123454: Integration with views bulk operations (vbo) is waiting for this patch to be committed in order to move forward with their end of the problem (the code from #35 on that thread). We probably need a re-roll of #25 against current -dev.

andrewbelcher’s picture

No re-roll required - still applies cleanly! Another +1 for getting this committed as it is working smoothly for me.

andrewbelcher’s picture

Status: Reviewed & tested by the community » Needs work
Issue tags: +Needs tests

Just had a quick chat with @bojanz on IRC, remaining tasks are:

- Update the minimum version of views to 7.x-3.12 as that's where #1802438: get_result_entities() Doesn't support revisions landed.
- Write a test to demonstrate it's working and prevent regression.

andrewbelcher’s picture

Status: Needs work » Needs review
Issue tags: -Needs tests
FileSize
6.36 KB
425 bytes

After another chat with @bojanz on IRC, we decided in light of the fact that there is currently no test coverage at all, we wouldn't hold this up on automated tests. Given that I have:

1) Updated the patch to include the views version dependency.
2) Done manual testing with 500 nodes with both the node base table and a search api db index using the patch from #1123454-89: Integration with views bulk operations (vbo).

Have set to needs review for the version addition, but other than that it hasn't changed since it was RTBC...

bojanz’s picture

Status: Needs review » Reviewed & tested by the community

I'll do a final test today.

alexverb’s picture

Works for me also with the search API patch.

Artusamak’s picture

I confirm that the patch is working for me too. Thank you!

joelpittet’s picture

Status: Reviewed & tested by the community » Fixed

#1123454: Integration with views bulk operations (vbo) is committed, and this one has been RTBC for some time, so I'm committing it. Thanks for testing this!

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

joelpittet’s picture

Considering reverting this as it seems to cause issue from some entities like ubercart. Not totally sure why yet so needs some investigation.

joelpittet’s picture

joelpittet’s picture

This looks like it needed a fix because of this patch too, FYI #2853029: views_bulk_operations_action_load_list not working