Lots of "Undefined index" notices...

Basically, things should be seriously broken if you're seeing that....
Will try to reproduce.

Update to the latest unpatched -dev. It has the ability to modify terms through the "modify entity values" action.
And make sure you have the latest Views, maybe an old Views version is causing a problem (though it's not very likely).

Do you use any special caching? Some module that could interfiere?

You just need to edit the VBO field (Views UI) and enable that action for your view.

Yeah, Views 3.1 should be fine.
A full module list might help. I'm going to be debugging a similar problem from one other issue reporter so it might help to see which modules you have in common.
Basically, a problem like this pops up from time to time, but nobody managed to track it down yet.

This is going to be hell to track down. There's another issue in the queue that is the same, and so far I haven't been able to pinpoint it to any cause. Even worse, reinstalling the site on the server causes the problem not to appear. Still, people are having it more and more.

What is your PHP version? What is your memory limit? Can you try to increase it?
What happens if you disable the APC module and try then?

Any chance you could try the core patch at http://drupal.org/node/1414510#comment-5533860 or maybe add some debug code to VBO that could help pinpoint the problem? If you have the Devel module, you could open views_bulk_operations.module, go to function
views_bulk_operations_form_validate() and add a dsm($form_state) at the top, before the switch starts. Then paste the output for every step until it fails (and then, of course).

Okay, forget about the core patch and the debug code. We tried that on another site, didn't help.

What I want is this:

What is your PHP version? What is your memory limit? Can you try to increase it?
What happens if you disable the APC module and try then?

Also, open your settings.php file, and see if there's a line mentioning "cache_form". If yes, comment it out. Sounds like an alternative form cache is not working correctly.
Not sure why yet, but let's first confirm that assumption.

Also see the conclusion to #1422070: All bulk operations broken

There is nothing else I can do without access to your setup.
And since not even you have access to your setup, that probably won't be easy.

The problem is on your side, in any case.

Okay, good to know.

when i select "Each action as a separate button", i got a lot of this notice. But when i first installed VBO, i don't have this issue.

so now if i disabled "Each action as a separate button" and switch back to "Dropdown selectbox with Submit button", it works now.

I had the same "undefined indexes" appear in my logs.

I believe I found a possible cause: when the Number of entities to load at once (under configure field > bulk operations > content > bulk operation settings )is different from the items per page (views > pager > pager options > items per page), the undefined index messages appear in the logs and a white screen appears after performing the operation.

I can confirm what ThePickwickProject said in #17 - I was getting the errors until I set the two values the same. However, I also found that setting both values to 1000 caused issues, so had to work back from there to a number that wouldn't generate a WSOD. Issue occurring in 7.x-3.0.

I can also confirm #17.

I have the same code in my local, test and production. But I get this error only on production.

The php version on -

• prod: 5.4
• test: 5.3
• local: 5.3

Memory limit on -

• prod: 256M
• test: 125M
• local: 512M

What I have noticed about the error is -

• When filter published is set to No and you publish a content it results in the white screen
• However if you set it to Any and publish/unpublish a content then there is no error.

Could this have to do with the php version? Any help would be great.

Thanks.

I'm getting the same:

Notice: Undefined index: operation in views_bulk_operations_form_submit() (line 716 of /var/www/phaidon/sites/all/modules/views_bulk_operations/views_bulk_operations.module).

Notice: Undefined index: select_all_pages in views_bulk_operations_form_submit() (line 714 of /var/www/phaidon/sites/all/modules/views_bulk_operations/views_bulk_operations.module).

Notice: Undefined index: step in views_bulk_operations_form_submit() (line 667 of /var/www/phaidon/sites/all/modules/views_bulk_operations/views_bulk_operations.module).

Notice: Undefined index: step in views_bulk_operations_form_validate() (line 624 of /var/www/phaidon/sites/all/modules/views_bulk_operations/views_bulk_operations.module).

#17 did not work for me. Any submission on a page where greater than 20 rows are displayed (selected or not) and the form throws the 500 error.

The only non-vanilla caching I'm doing is directly on the database level -- mysql data cache. I've got tons of RAM.

VBO version 7.x-3.0-rc1

Same here.

Having the same issue. Running php 5.4 on localhost.

Notice: Undefined index: operations in views_bulk_operations_handler_field_operations->init() (line 17 of C:\BitNami\wampstack-5.4.18-0\apps\drupal\htdocs\sites\all\modules\views_bulk_operations\views\views_bulk_operations_handler_field_operations.inc).

Warning: Invalid argument supplied for foreach() in views_bulk_operations_handler_field_operations->init() (line 26 of C:\BitNami\wampstack-5.4.18-0\apps\drupal\htdocs\sites\all\modules\views_bulk_operations\views\views_bulk_operations_handler_field_operations.inc).

#17 didn't work for me either.

I just tried reducing my pager settings to only display 16 items.
From there, I was able to perform my VBO custom rule on over 300 items..

hope that helps someone else until the issue is resolved.

removed some examples which were related to field rather than VBO

I already provided a ton of advice regarding possible problems and solutions in this thread.
So far I've been unable to find any bug in the VBO code, it has always been a server setup issue (memory limits, mysql configuration, caching).

#23 is unrelated I think, there's another issue that mentions it: #2077825: errors at emptying the cache and I think it's triggered by old views.

Closing this issue. Reopen with a patch.

One more note that #17 worked for me. I set Number of entities and Items per page to 50, and my updates worked fine; I had been getting a WSOD and undefined index error messages:

Notice: Undefined index: field in field_widget_field() (line 578 of public_html/modules/field/field.form.inc).
Notice: Undefined index: instance in field_widget_instance() (line 603 of public_html/modules/field/field.form.inc).

Thanks, ThePickwickProject, for the tip!

What worked for me was setting the number of entities to load at once same as items per page, as @ThePickwickProject suggested in #1424754-17: Lots of "Undefined index" notices.... I set it to ten both places and it works now, no more white screen.

Having the two numbers be the same also solved another problem: Before, if I batch-deleted fx 1500 nodes using VBO, it would only delete maybe half of them, and I would need to repeat the process many times over. Just now, I deleted 12.000 nodes in the first go.

I still have this problem when selecting "Each action as a separate button", whether confirmation step is enabled or disabled. Views 7.x-3.23, VBO 7.x-3.5+3-dev (2019-May-16).

I traced the code to views_bulk_operations_form_submit(). It got called twice upon submission, the first time $form_state['values']['operation'] is set to "action::views_bulk_operations_modify_action", but the second time $form_state['values']['operation'] is no longer there, instead having $form_state['values']['action::views_bulk_operations_modify_action'] set to "My button label" instead.

I'm too lazy to trace at which step the "operation" value is no longer part of the form. Instead, I added this chunk of code to check for the value instead:

switch ($form_state['step']) {
    case 'views_form_views_form':
      $form_state['selection'] = _views_bulk_operations_get_selection($vbo, $form_state);
      $form_state['select_all_pages'] = $form_state['values']['select_all'];
  
     // added fallback for operation
      if (!isset($form_state['values']['operation'])) {
        foreach (array_keys($form_state['values']) as $key) {
          if (substr($key, 0, '8') == 'action::') {
            $form_state['values']['operation'] = $key;
            break;
          }
        }
      }

      $options = $vbo->get_operation_options($form_state['values']['operation']);
      $form_state['operation'] = $operation = views_bulk_operations_get_operation($form_state['values']['operation'], $entity_type, $options);
      if (!$operation->configurable() && $operation->getAdminOption('skip_confirmation')) {
        break; // Go directly to execution
      }

Should serve as an ad hoc fix for now, in the process of migrating the whole site to Drupal 8 anyway.