Load a list of entity from a VBO View doesn't work (AJAX error)

I have a similar issue. Following updating to 3.1, any attempt to load a list from the current URL (for example using $arg1 = arg(1):) fails. This was working perfectly before the upgrade. Thanks.

edit: just went back to 3.0 dev version which works fine.

I'm using rules to load a list of entities with VBO, and I think it's the same problem.
Using rules 2.2, vbo 3.1, views 3.5, ctools 1.2.

When editing the rule I get the errors:

Notice: Undefined index: node in eval() (line 11 of ...views/plugins/views_plugin_argument_default_php.inc(53) : eval()'d code)
Warning: array_keys() expects parameter 1 to be array, null given in eval() (line 11 of ...views/plugins/views_plugin_argument_default_php.inc(53) : eval()'d code)
Warning: array_pop() expects parameter 1 to be array, null given in eval() (line 11 of ...views/plugins/views_plugin_argument_default_php.inc(53) : eval()'d code)

In rules debug, right after it gets to the loop it warns: The variable or parameter group is empty.

I also tried using the current 3.x dev branch, and then downgraded to 3.0 but I'm still getting the same errors.

I have a similar issue. I have created a rules component where I use the "Load a list of entity objects from a VBO View" rules action. When I execute the Rules Component manually all works as expected and the entity list is loaded just fine. When the Rules Component is executed by the Rules Scheduler on cron nothing is returned though.

Have any of you found a solution?

Patch flying in.

i'll just chime in with a relatively useless comment; just realized a view we had is very busted after upgrade to 3.1

part is due to this issue; but other issues as well which i see posted.. no way to not batch, can't skip confirm, etc.

reverting back to 3.0 fixes everything

The skip_confirmation option is still there and hasn't changed since forever.
I'm gathering feedback on the batch issue in #1902104: Allow batching to be skipped.

Can someone please test the patch in #8 and report whether it works for them?
Maybe it's time to remove the rules integration in favor of http://drupal.org/project/views_rules if people are finding it problematic.

Patch from #8 didn't work.

#11: "works"
#12: "works"
#12: "but it still returns nothing if it's fired by cron" - this is to be expected as anonymous cron user does not have vbo permissions
#14: "did not work" - please elaborate!

#8 works for me. I do not use cron to run rules.
VBO - 7.x-3.1
Rules - 7.x-2.3

Thanks for testing. Committed.

I was having this same error using a view which pulled content from the user's OG group. The error was only occurring on Mac (no idea why) whether using Safari or Firefox and on multiple different Mac laptops / desktops... Every PC I tried did not experience this issue.

#13 from user blackclover is what ultimately fixed the issue. I simply disabled SQL rewriting and this error has vanished. Thanks!

Still getting this issue using Views 7.x-3.2, Views 7.x-3.8, Rules 7.x-2.7

Ajax circles around, then displays nothing.

Same problem here as #20. I have been using View Rules and Rules Bonus but will like to switch to VBO for some good reasons

same problem as #20 and there's no error logged on 'Recent log messages' page.

Getting An AJAX HTTP error 502 every time I select either

• Load a list of entity ids from a VBO View
• Load a list of entity objects from a VBO View

and cannot go on adding the action to the Rule.

Using

• VBO 7.x-3.2+15-dev
• Views 7.x-3.8
• Rules 7.x-2.7

Should we have any particular View with specific settings in place before being able to use that action?
Thanks

Any more resolution here? Patch is still not working on dev.

At one time only one type of entity can be loaded in views.

I can see admin/content are perfectly coming here. Can anyone add steps to reproduce here?

Same error ajax

VBO 7.x-3.3
Rules 7.x-2.9

Any solution ??

Thanks

This can't be reproduced with a default installation containing only a few views. You may need hundreds to reproduce.

The problem is that views_bulk_operations_views_list() in views_bulk_operations.rules.inc is building all available views to detect the VBO-enabled ones. It needs a more performant way to do the detection.

Here is an alternative way that checks the views_bulk_operations field in the base view without building it.(no patch sorry)

function views_bulk_operations_views_list() {
  $selectable_displays = array();
  foreach (views_get_enabled_views() as $name => $base_view) {
    foreach ($base_view->display as $display_name => $display) {
      // Check the vbo field.(Check the default display if using the default fields)
      if (!empty($display->display_options['fields']['views_bulk_operations']) || ($display_name !== 'default' && empty($display->display_options['fields']) && !empty($base_view->display['default']->display_options['fields']['views_bulk_operations']))) {
        $selectable_displays[$base_view->name . '|' . $display_name] = check_plain($base_view->human_name) . ' | ' . check_plain($display->display_title);
      }
    }
  }
  return $selectable_displays;
}

Same error - works fine when run manullay, running with a cron and VBO doesnt have info to loop through

VBO 7.x-3.3+2-dev
Rules 7.x-2.9+4-dev

Tried #27.... no luck

Cheers

#27 did the trick on an OpenAtrium distrib (where I added Commerce)

VBO 7.x-3.3
Views 7.x-3.14
Rules 7.x-2.9

For me, this error was resolved simply by changing my PHP version. PHP 5.3 produces the error, while 5.4+ does not.

The code in #27 can be problematic for Views that load a lot of data. Here are some steps to reproduce for Simplytest.me:

- Spin up with these projects: views_bulk_operations, rules, token, realname.
- Generate 5200 users (it will error out, but the users will get generated).
- Import this View: https://gist.github.com/wizonesolutions/d1720b2cc24188b9de13fb544107013d (admin, structure, views, import view, paste it).
- Go to the Rules page (admin, configuration, workflow, rules).
- Add a new Rule...pick any event you wantf
- Add a new Rule action. Pick one of the VBO actions.

Expected: selection form with list of Views loads quickly (not more than 5-10s)
Actual: Due to rendering the Views, and one of the Views listing all 5000-something users, it takes around 30-45s on Simplytest.me (which is actually a little fast compared to the client site where I am seeing this).

views_get_enabled_views() can be pretty slow because it checks cache, exported files and db.

Then for every active view we get clone it(may be unnecessary) if we can avoid building the view to get the field info from _views_bulk_operations_get_field()

So it looks like there is room for improvement both in views_bulk_operations_views_list() and maybe wider in views_get_enabled_views()

@wizonesolutions Try this patch, I pulled what I think are the necessary things out of the build() call to get the field handlers initialized and avoid looping through views that aren't using fields.

Oh, this looks much better. List of Views seems to be the same as before. +1 from me. Might be good to refactor out that part of Views into a function that we could reuse instead of duplicating code...but I don't think that should block this.

I've committed and pushed this to -dev

@joelpittet somehow this patch never made it into the latest dev. Once I patched the latest dev all was good again.

It looks like it's there from this end. I can't re-apply it and you can see it committed in #35 above.

Tricky, we recently updated when a new version of dev came out and that was when the issue came back. Perhaps it is specific to our setup but I did have this on 2 completely different servers.

This update included in the 7.x-3.4 release seems to break my Rule that has an action "Load a list of entity objects from a VBO View." Not exactly sure what is happening but I see "Unable to get variable entity_list, it is not defined" in the logs.

Views Bulk Operations (VBO) 7.x-3.4
Rules 7.x-2.10
Views 7.x-3.16

This is not in 3.4, it's in the dev release.

Same issue with VBO 7.x-3.5 : "The variable or parameter node is empty." in the logs .
I'm obliged to downgrade to 3.4.