I have a simple view listing some users and I use VBO to execute an action on the selected users. This used to work, but now it seems to have stopped working - the selection is lost after the action is configured. I have verified that $form_state['values']['views_bulk_operations'] contains the correct selection on the configuration page, but after submitting and getting to what should have been the confirmation page, $form_state['values']['views_bulk_operations'] has all values set to zero. And of course I get the error message "Please select at least one item."

I have tested this with the simple mesage action (system_message_action).

I have Drupal 7.10, Views 7.x-3.1 and VBO 7.x-3.0-beta3.

PS! I'm wondering if #1348552: Token replacement for system actions not being done on user views is related.

Comments

bojanz’s picture

bojanz commented

I don't have any problem with user operations.

1) Test the -dev version.
2) Test another view (admin/content2), so that you know if it's just users, or other entity types as well. Sounds like it should be broken across the board.
3) Debug your modules, see if there's any that might cause problems (usually due to caching or form altering)

hansfn’s picture

hansfn commented
Title: User bulk operations broken? » All bulk operations broken

Thx a lot for the quick reply. I had of course cleared the cache (like a million times), but I was wrong that the problem was related to users only - it's broken across the board.

I have tested with the dev version - same problem. I have disabled and uninstalled all non-core Views modules and cleared the cache again - same problem.

I don't see that any of the other modules should alter any Views Bulk Operations forms. I just don't get it. I'll start with a fresh/empty Drupal 7.10 and see if I can recreate the issue.

Thx for your time so far.

hansfn’s picture

hansfn commented

OK, as promised I took a fresh/empty Drupal 7.10 and installed the same modules as on the site where the bulk operations are broken. (I even ran a recursive diff to verify that the same versions were installed.) "Unluckily", bulk operations worked on the fresh site after installing and enabling the same modules. (I ran a diff on the output from "drush pm-list" to ensure that the status for the modules were the same.)

So basically I wasted two hours trying to find the module causing my troubles. Since this is a real problem for me (and another user I have communicated with), I'm willing to spend even more time on this. Do you have any hints as to where I should look? Any variables related to VBO operations? (I have checked that the settings for Views are identical on the two sites.)

I could give you access to the two sites, but not SSH access. I understand that you probably don't have time.

bojanz’s picture

bojanz commented

So it's working on a copy of the site that has the same modules? That points to server config.

hansfn’s picture

hansfn commented

1) It's not an 100% identical copy - the new site just has the same modules installed and enabled. (I hoped/expected to find the guilty module this way.)
2) The new site is on the same server - just a new installation in sibling folder.

In other words, I don't think it's a server config issue. And VBO worked before.

bojanz’s picture

bojanz commented

Odd. Create a drupal account that has access to VBO, Views, and devel/php, and email me the details, I can try and debug it.

hansfn’s picture

hansfn commented

Thx to the skills of bojanz, it became clear that the form data was definitely disappearing from cache. It was a user error from my side, not related to VBO:

I had

    $conf['cache_default_class'] = 'DrupalFakeCache';

in my settings.php - I added it not too long ago when doing some development - without the needed

    $conf['cache_class_cache_form'] = 'DrupalDatabaseCache';

I'm sorry for having wasted everyone's time.

hansfn’s picture

hansfn commented
Status: Active » Closed (cannot reproduce)
bojanz’s picture

bojanz commented
Status: Closed (cannot reproduce) » Closed (works as designed)

Okay, so we now know why a problem like this can happen.
Closing this issue, and linking it from other similar ones.

SGhosh’s picture

SGhosh commented

Confirming #7 solved the problem. Thanks @hansfn.