Old views don't get updated correctly, processing hangs

I am assuming you are executing VBO from the actual page, and not as a part of the preview in the Views admin UI?
This problem usually points to a module interfering in the process, so you need to check what else you have installed that might affect it (maybe a faulty theme? Are you using the Seven theme?).

As I have - as it seems - a similar issue (http://drupal.org/node/1817488 now tagged as duplicate) I jump in here.

@bojanz: I have tried to figure out which module which can be interfering, but no success so far. I am using Seven as admin theme and Omega 3 as frontend theme (and I am not running the view from the preview in Views).

• I have upgraded to Drupal 7.16.
• I have inactivated APC, Devel, Superfish, jQuery UI Multiselect, jQuery Update 7.x-2.2, and Admin menu.

Do you have any other suggestions as where to look for interfering modules/theme functions?

I also have inactivated the module Organic Groups create permissions which I now interferred with VBO. After inactivation I did rebuild the permissions. But it didn't help.

Now I reverted back the site again to before all upgrades etc. I just wanted to check again what happens if I recreate (clone) the view "Content" (/admin/content2) from scratch. And it actually works fine until I activate the function "Modify entity values", then I get the same error again (it doesn't matter if I use this function or another - no function works after this activation). If I then deactivate "Modify entity values" and tries again, the error still persists!? I have tried this two times (recreated the view), so I can reproduce the error.

What do we make of this? Does the view get corrupted somehow when I activate "Modify entity values"? If so, what can cause that?

No, in the roll back all disabled modules are activated again.

Have you tried to clone the view "Content" and test? And then add "Modify entity values" and test? (See #4.)

I am not at my computer right now, you find it if you click on the "field" Bulk operations (or something like that). But if you don't know that, your problem is not exactly the same as mine. Do your further testings on a clone.

Just to summarize my testing so far:

1. I clone the view Content (admin/content2).
2. I test and it works fine to e.g. unpublish a node.
3. I add the function "Modify entity values" to my cloned view.
4. I test and it does not work any longer to to e.g. unpublish a node (i.e. I am not using the activated function "Modify entity values").
5. I test to modify an entity value, and it does only work if the activated function "Modify entity values" is enqueued (direct modify does never work). So if the function is activated in the view I have to use it and it needs to be enqueued.
6. I deactivate the function "Modify entity values" from the view, flush all caches, and do step 2 again, but now it does not work to e.g. unpublish a node.

For me the error is always the same (see http://drupal.org/node/1817488), which is not exactly the same as for dbkern who gets a "parserror" (see #5), while I get a "access denied".

Anyone who can give any more clues where to look or how to test to isolate the problem(s)?

Same problem, in 7.x-3.0 but also in 7.x-3.x-dev. Looks like a bug to me.

This happened to me, but I don't have "Modify entity values" selected and I never have. It was working until I chose the Enable "Select all items on all pages". Afterwards I have the same behavior described above.

If I delete the cloned view and re-clone it and then don't check "Select all items on all pages" then it works, obviously this is not ideal.

I am having the exactly the same problem.

Hello all,

I spent some time digging around in views_bulk_operations.module and dpm()ing a few things. It appears the problem is coming from the "Number of entities to load at once" (entity_load_capacity) setting. At least in my case that was it. I was using the admin_content view that comes with VBO and the entity_load_capacity wasn't set (I think the view is a bit old because all the vbo settings don't appear to be keyed correctly...). Eventually when the batch operation tries to use this value to determine how many records to process per batch, but since it's empty/null, we end up in an infinite batch loop.

The fix is rather simple: Just set the "Number of entities to load at once" setting to some numeric value. It's supposed to default to 10.

Moving forward, I think the "Number of entities to load at once" setting could warrant a little extra validation (required, must be an integer). Either that, or add a default value to $vbo->get_vbo_option('entity_load_capacity') in _views_bulk_operations_execute()... or both... Also, I think the default view should be updated to include the entity load capacity setting.

I've attached a patch that does the following:

• Updates the default view to include the entity load capacity setting (I just enabled, added the value, and exported back into views_bulk_operations.views_default.inc)
• Adds a little validation to the entity_load_capacity setting to check that it's numeric and greater than 0
• Incorporates the default values defined in the field handler to calls to get_vbo_option() in the module file

I feel that this pretty well covers all bases to avoid the infinite loop in the batch process function. It might look like a heavy patch, but most of that is just the default view update. The other changes are quite small.

is the patch only works for 7.x-3.x-dev? i applied it to 7.x-3.0 and the problem still persists.

currently i fallback to use the 7.x-3.0-rc1 and it works fine.

@ykyuen
You have an old view. You need to recreate it (remove and readd the VBO field). That will fix it.

Thanks for your reply. #15 patch works perfectly.

@drclaw: thanks for your input in #15!

Before I saw your answer, I tested to recreate the view "admin/people2" manually from scratch. I ended up with a view which is the same as "admin/people2", except for one thing: I don't get the bulk progress bar. And it works fine, even with the "Select all items on all pages" setting activated. The "Number of entities to load at once" setting is automatically set to the default value of "10".

Is it possible get the bulk progress bar in a manually created view?

I believe you get the bulk progress bar only when you have more items than the "Number of entities to load at once" selected. If you have less, the function is just invoked directly... Could that be the problem?

Okay, looked into this.

The problem is in the buggy VBO update code, by updating the settings it unintentionally wipes out the defaults, so we have cases where crucial settings don't have any default values. The fix is a one liner:
http://drupalcode.org/project/views_bulk_operations.git/commitdiff/f5af1...

Also, removed the default views completely: #1844708: Remove the default views now that admin_views is stable.

Please test tomorrow's 7.x-3.x-dev, I will tag 7.x-3.1 in the next few days.