VBO loses selection with caching module

Thanks for the report. I wasn't able to reproduce this behaviour on my side unfortunately, so we'll need to debug this together:
* Does it happen with node views as well ?
* Does it happen with the latest dev ?
* Does it happen on another machine ?
* Are other multi-step forms (not related to VBO) working correctly ?

Thanks for your patience :-)

I'm using the views -dev release and having a similar problem. With node views I can select a single page worth and it carries through to the submission page and everything works fine. When I try the select all link and then submit I get to the confirmation form with no data selected. I'll try updating to the VBO dev release and see if the problem persists.

just updated to the DRUPAL-6--1-4 release and the bug still occurs.

So are you saying it's just the select all option that's not working?

for me it's the select all. i'm not sure if they're the same bug or not but part about the selection not making it to the confirmation form is the same.

I would really like to reproduce this problem. Can you please both send me your Drupal configuration (versions, modules, OS) ?

uh yeah easier said than done... i'm wishing dries hadn't been blocking that feature request to give you a downloadable status report with enabled modules.

@drewish: After spending the better part of an hour downloading and enabling the modules, I did the following:
* Generate 50 nodes (pages and stories)
* Open the stock VBO (admin/content/node2)
* Check the select all box, then click the select all button
* Apply an action (change author in my case)
... and everything worked :-( 50 nodes processed.

So I got some questions:
1. Does the select-all fail on the stock VBO above or just a specific one you created? If it's the latter, then please export the view and attach it here
2. Would the browser be involved in the problem? If you use Firefox + Firebug, please locate an input element whose id="edit-objects-select-all" (underneath the node list). If you click the select-all button, its value should change to 1
3. Re-reading your original comment here you said "[..] then submit I get to the confirmation form with no data selected." Do you mean the confirmation form shows with zero nodes?

1) tried the changing owner with the built in view and the nodes made it to the confirmation form. tried adding the node save action to the view and it worked then as well. need to re-try with my view/export it.
2) firefox 3
3) right you get to the confirm form and it says 0 nodes selected.

To add to the confusion on this issue...I'm encountering this as well. Sometimes.

We 2 servers managed by svn - test and live. I also use my laptop to develop (also svn). The test server has this problem. The other two servers do not have it.

I'm using a theme override on hook_views_node_selector.

I use a hook_views_pre_render to modify an attachment on this view.

I haven't tested using another theme or commenting out the hook_views_node_selector yet.

So...that's another data point, but still not enough to really know what's going on.

To all the reporters here: can you please try the latest DRUPAL-6--1 release from CVS ? I fixed an issue (#342378: Bulk operations operates on all nodes in nodes table when select all nodes in view is chosen) that could be related to the present one. Thanks!

I had the same problem. I was using D5.8 and VBO 6.x-1.4

Upgrading to D5.9 solved the problem for me. -- YEAH!
Stefan

Updating to the latest code seems to have fixed it for me.

Given that and Kratib's comment in #12, marking fixed.

Updating to the latest code fixed this in my testing installation. But I still have the same problem as greggles with my production environment....

Related production environment modules:
Views Bulk Operations 6.x-1.x-dev
Content 6.x-2.5
Embedded Media Field 6.x-1.12
Embedded Video Field 6.x-1.12
Messaging 6.x-2.x-dev
Simple Mail 6.x-2.x-dev
Content Notifications 6.x-2.1
Notifications 6.x-2.1
Notifications Lite 6.x-2.1
Organic groups 6.x-2.0
Organic groups access control 6.x-2.0
Organic groups Views integration 6.x-2.0
Organic groups vocabularies 6.x-1.0
Better Formats 6.x-1.1
Token 6.x-1.12
Views 6.x-2.6
Views UI 6.x-2.6

@Pasi:

* Do you encounter that problem with the stock view at admin/content/node2?
* At which step do you encounter it? Configuration? Confirmation? Execution? What happens if you set the view style to skip the confirmation on an action that has no configuration page?
* Does it happen for VBOs with nodes and users alike?
* Does it happen *only* when you click the "Select all objects across pages" button or even when you don't?

Can you please try the following experiment: Comment out the lines that read:

  unset($element['#options']);
  $element['select_all'] = array('#type' => 'hidden', '#default_value' => @$element['#value']['select_all']);

in function views_node_selector_process in views_bulk_operations.module. How is the behaviour now?

Thanks for your help.

* Do you encounter that problem with the stock view at admin/content/node2?

-It works with this view.

* At which step do you encounter it? Configuration? Confirmation? Execution? What happens if you set the view style to skip the confirmation on an action that has no configuration page?

-The confirmation shows "You selected the following 0 rows:". If I skip the confirmation step, I don't get any announcement. The page just refreshes.

* Does it happen for VBOs with nodes and users alike?

-It seems to work with "og_members" -view.

* Does it happen *only* when you click the "Select all objects across pages" button or even when you don't?

-Yes this happens only when I select "Select all xxx rows in this view."

Can you please try the following experiment: Comment out the lines that read:
unset($element['#options']);
$element['select_all'] = array('#type' => 'hidden', '#default_value' => @$element['#value']['select_all']);

in function views_node_selector_process in views_bulk_operations.module. How is the behaviour now?

-Now it selects (and works) only the first page.

Thank YOU for your help :)

Please try the latest dev release (12 hours from now). Is it any better?

Thanks but it's still the same... No rows were processed.

The problem is that I am coding blindly since I can't reproduce the problem on my end. Would it be possible for you to grant me access to the installation where this problem exists? Please contact me privately for the details.

Thanks, but I managed to solve this problem on my own. I commented out the following line in function _views_bulk_operations_adjust_selection:
$view->ignore_fields = TRUE; // we don't need the fields here so we tell our style plugin to ignore them

Can you say is there any downsides with this solution? Will there be a performance hit?

Crell: I don't mind doing a better job at emulating trigger.module :-) Can you please describe a scenario to reproduce some of the problems you found?

Pasi: Thanks for your feedback. I don't understand why $view->ignore_fields would affect the selection, so I need to look deeper into the query builder. From a performance perspective, I guess the view will pull in all fields instead of just the node IDs, which will increase memory consumption.

Crell: I see what you mean. The "Send email" operation is designed to be used with nodes, not users. The recipient field can be filled with the token "%author" which will pull the node author's email. I tested this with a VBO for nodes and it works correctly. The reason why this action also appears in a user VBO is that its type is marked as "system", which is ambiguous as far as VBO is concerned - VBO will show it for any view type.

This doesn't seem to be related to the original case of the selection being lost, though. Can you confirm that they are 2 different issues on your side?

Pasi: ignore_fields turned out to be my own code :-o I removed it because it didn't do any good. Thanks for the help!

After upgrading to the latest version of views (2.8), this is still an issue... One thing I noticed was I got a max packet MySQL error; this might be something to look out for. Might want to throw a warning or split the query up if its larger than the max packet

  // Get maximum packet size for mysql
  $max_packet = db_result(db_query("SHOW VARIABLES WHERE Variable_name = 'max_allowed_packet'"));

If you need an example usage of $max_packet; over in the boost module you can look at boost_crawler_add_alias_to_table()

@mikeytown2, can you confirm the relationship between the lost selection and the max_allowed_packet? I couldn't repro this on my machine so I'd appreciate a confirmation before embarking on a long debugging session.

real easy way to make this happen is to set max_allowed_packet to 1M & do a VBO opp on 1,000 nodes; should be able to reproduce it.

Great! That did it. But I don't understand the general approach to fixing max_allowed_packet errors. Can you explain it briefly?

We run into this issue with v6.x-1.8 (snapshot from 2009/09/09) but it's confusing - it happens fairly frequently and only on our production site instances, not our dev site instances. The key differences between our production and dev sites are:

• Memcache is used on production for the cache tables,
• Production has obviously a higher load, more concurrent sessions, the cache being cleared more often.

FYI I've successfully used VBO to delete hundreds of objects at once on a dev site, but on production our users can't even do one at a time, so I don't think max_allowed_packet is a part of the problem.

It's sorta complicated... I have a patch here against core that shows how to account for the max packet issue:
http://drupal.org/node/512962#comment-2519358

In short you need to split up the query so it's smaller then 1MB.

I'll work on this during this week.

Postponed to next week (Apr 3). Sorry!

I work with DamienMcKenna and I've got some more information about the bug.

It definitely appears to be related to the size of the result set.

I am attempting to delete around 12k image nodes for one of our sites. On our dev/test server there are no problems. It will run the whole 12000 node batch. The only place this is a problem is our production servers.

I was able to delete the rows manually on the production server by altering the view to show 300 rows at a time. It appears out production server will timeout at any more than that. I was unable to find an upper bound for the result set size. Deleting sets of 600 - 1000 rows of other content types does not appear to be an issue. I can't do extensive testing of this type during the day.

As Damien notes, our production servers have a higher load, concurrent sessions, etc... however my site has not launched yet.

I have concluded that memcache is not a factor in the problem; I do not have memcache enabled. If needed, I can compare the configurations on our dev/test vs prod servers for specific values. I obviously cannot post our complete configuration for security reasons.

KevinH

Kevin, something to check is whether it works differently if you set the actions to be processed by BatchAPI or let run without it (settings in the View style).

I'm running into this error even with confirmation disabled.

Subscribe. Have this problem with 6.x-1.9, workaround was to disable the confirmation. Which is not optimal but could find no other solution thus far.

I'm running into this error even with confirmation disabled.

having this problem with 6.x-19 using Views 3 dev.

Same problem here! Any news?

All the latest posters: can you look at #18 above and answer those questions? It will help me characterize the different cases.

* Do you encounter that problem with the stock view at admin/content/node2?
Yes

* At which step do you encounter it? Configuration? Confirmation? Execution? What happens if you set the view style to skip the confirmation on an action that has no configuration page?
In Execution.

* Does it happen for VBOs with nodes and users alike?
Yes.

* Does it happen *only* when you click the "Select all objects across pages" button or even when you don't?
It happen when select one element or multiple.

Regards,
eZar.

I'm running into this problem only when using memcache module with memcache.inc active.

For me it's a memcache module issue, since i have no problem using memcache.db.inc in settings.php.

I ran into this issue when using Cacherouter with APC. The issue was resolved for me when I switched back to db caching in settings.php, i. e.:

$conf['cacherouter'] = array(
  //Cache in db by default, don't use APC as 
  //it cuts off URL paramters sometimes
  'default' => array(
    'engine' => 'db',
    'static' => FALSE,
    'fast_cache' => TRUE,
  ),
);

This happens we me as well. Here are some details.

Pressflow 6.19.94
Views 3 dev, as of 8/1/10
Memcache 6.x-1.x-dev as of today and using memcache.inc
views_bulk_operations-6.x-1.x-dev as of today

* Do you encounter that problem with the stock view at admin/content/node2?
I don't use admin/content/node2 so this isn't really a valid test for me.

* At which step do you encounter it? Configuration? Confirmation? Execution? What happens if you set the view style to skip the confirmation on an action that has no configuration page?
I have a series of exposed filters, which I use to reduce the result set. I then select a single result (which is a node) and then "Modify Node Fields", Execute. This takes me to a second page where I modify a taxonomy term which is presented in a drop-down box. I click Next, and there is no confirmation step. I am then returned to the original view with the message "No row selected. Please select one or more rows."

* Does it happen for VBOs with nodes and users alike?
Again I only use this for nodes, so I don't know how it would work for users.

* Does it happen *only* when you click the "Select all objects across pages" button or even when you don't?
I don't even have that button on my view, so the answer is no.

The lines that you had suggested be commented out in #18 no longer exist in the module that I could see. For Memcache, I am caching: cache, cache_menu, cache_filter, cache_form, cache_block, cache_update, cache_views+cache_views_data, cache_content, and cache_apachesolr in their own bins.

Nothing to indicate a problem shows up in the Drupal log or in the Apache webserver log.

Bouncing the memcache daemons and the http daemons do not help.
I removed the memcache bins for views/views_data and that did not help.
I removed the memcache bin for cache/default and that did not help.
I removed the memcache bin for content and that did not help.
I removed the memcache bin for filter and that did not help.
I removed the memcache bin for form and that did not help.

Finally, I disabled memcache completely in settings.php. This invokes the batch API and works properly. It's interesting to note that in the memcache/broken state, the batchAPI screen with the progress bar never appears.

My conclusion at this point is that somehow this is interacting negatively with the memcache module. This was working for me previously with Memcache module 6.x-1.x-dev (2010-Sep-21) and now I'm using 6.x-1.x-dev (2010-Sep-29). Assuming something else here isn't broken, it's likely that whatever changed in that module between the 21st and 29th could be part of it.

One other note - I rolled back the Memcache module to 2010-Sep-21 and it fixed the problem - even after manually incorporating the security fix from #828664: Blocked user session regeneration. I can suggest with a higher degree of confidence that the most recent problem with this is related to a commit in the Memcache module between the 25th and 29th, and whatever broke it isn't the security fix.

rjbrown99: Thanks for the great detective work. I will try the memcache module as you describe.

Might be related to #936218: VBO loses selection with memcache module.

I'm not using memcache yet i have the same issue. I think that any kind of third-party caching cause this.
I'm using Boost and Cache router

I have observed this problem both with the memcache module as well as when using cache router without memcache storage.

Interestingly, one workaround was to reduce the number of fields in the view to a minimum and show only Node-Ids.

Addendum: Other interesting workaround, if I apply an optional filter without any selections set (eg myurl?keys=&tid_op=or&tid=), it works, without it does not.

Thanks to everyone who provides clues here. I now feel pretty confident to say this issue is related to caching modules.

@infojunkie
True except if MySQL hits the max packet size during the query. Default is 1MB & if working with thousands of nodes it is easy to hit this limit. This doesn't have an easy solution so might be something to document.

@mikeytown2: I suggest to move the max_packet_size problem to #869776: Batch API performance/memory Question/Suggestion. Please add your input there.

same issue, subscribing

@protosplasm: You mean you are using a caching module that you are sure is causing the selection to be lost?

Maybe it is useful for someone:
In my case the problem was caused by the caches. The amount of data written by VBO into the session cache can be quite huge. As a result the caches filled up and the write to cache requests silently failed. As all other cache requests were relatively small compared to the VBO data, it was not directly observable for me. I have completely reworked my caching strategy and since then I have not observed any problems with VBO.

Tagging for next release.

@infojunkie: No on both accounts. I need to look into it further. I have no select all button unless I have a pager. If I click the select all button, nothing selects even though it says it selects. Nothing happens either. The only caching modules I have are on the apache server side mod_mem_cache and eAccelerator. I need to look at this more closely when I have time. Sorry for any confusion.

has anyone found any workaround for this problem? i tried the suggestion from #53 but it doesn't work as i expected. tried disabling even drupal's caching, but the same thing happens.

To all posters here: since I've been unable to reproduce this locally so far, I'd be grateful if one of you would consider granting me access (Drupal admin and SSH) to your dev server where I can debug this. Contact me privately with the details.

i found a nice workaround from suggestions in this thread. my site requires me to tag 4 taxonomy terms to a filtered view of about 40k nodes, with hundreds of such bulky view to deal with. i use vbo with batch api to carry out this task.

i used httpd 2.2, mysql 5.1 (innodb), php 5.3 (memory = 512m), varnish (malloc = 2g), memcached, pecl-memcached (1 instance = 128m) and pecl-apc (shm = 512m).

i only allow memcached to cache tables with the these prefixes: cache, menu, term. memcache.db.inc is used in settings.php.

in my local machine where memory is in abundance, i observed that the size of the batch table grows significantly with my task, sometimes to 100m. on my cloud, i found out the same thing too.

what i did was adjusting the max_allowed_packet to accordingly, currently at 200m. this line is put in mysql configuration file. things are working very well now so far. also, minimise the number of fields shown in the view. it does help reducing the batch table size, form my observation.

@infojunkie: i'll try to allow ssh and site admin access.

i found a nice workaround from suggestions in this thread. my site requires me to tag 4 taxonomy terms to a filtered view of about 40k nodes, with hundreds of such bulky view to deal with. i use vbo with batch api to carry out this task.

i used httpd 2.2, mysql 5.1 (innodb), php 5.3 (memory = 512m), varnish (malloc = 2g), memcached, pecl-memcached (1 instance = 128m) and pecl-apc (shm = 512m).

i only allow memcached to cache tables with the these prefixes: cache, menu, term. memcache.db.inc is used in settings.php.

in my local machine where memory is in abundance, i observed that the size of the batch table grows significantly with my task, sometimes to 100m. on my cloud, i found out the same thing too.

what i did was adjusting the max_allowed_packet to accordingly, currently at 200m. this line is put in mysql configuration file. things are working very well now so far. also, minimise the number of fields shown in the view. it does help reducing the batch table size, form my observation.

@infojunkie: i'll try to allow ssh and site admin access.

subscribing

To all posters here:
Can you comment on whether deleting nodes via the core content admin page (admin/content/node) works or not? I was able to verify that at least on one installation, when VBO fails with the confirmation message, the core admin page also fails (with the Delete operation for example).

I debugged this issue on a site running Cache Router with APC as caching engine. Increasing the setting apc.max_file_size from 1M to 10M solved improved the issue (i.e. less failures). Please try similar settings on your caching engines and let me know if there's any improvement.

The problem with APC is that it silently fails if it is unable to save form data because of memory allocation errors.

Subscribing: Having problems with Memcache + VBO conflict.

@Katrina B: Can you confirm that you see the same problem on the core content admin (admin/content/node)?

Actually, I'm here because my issue was marked as a duplicate, and I was redirected to this thread. My problem is described in my original issue: http://drupal.org/node/936218

To clarify #75:

I need posters here to test the *core* content admin page (admin/content/node) with your caching module turned on. Try to delete content: is the selection lost after the confirmation dialog?

tested deleting nodes with admin/content/node with the caching modules turned on and the apc cache size increased. all fine and worked well.

Re #78: Thanks for the feedback. VBO still broken with increased APC cache size?

referring to post #70, i reverted the memory settings back to default as per original and just modified the apc.max_file_size. so far so good. but then it's on a cloud server. anyone on a shared hosting want to share?

I don't know if I've run into exactly the same issue, but it seems similar in nature.

Key items:
Drupal 6.19
Views 6.x-2.11
VBO 6.x-1.10
Authcache 6.x-1.x-dev
Block Cache Alter 6.x-1.4
CacheRouter 6.x-1.x-dev

Problem Description:
When selecting individual rows, the confirmation screen shows the wrong items. And the wrong items are updated...I haven't tried the scenario without a confirmation screen. Happens on both user and node views.

The problem only occurs with exposed filters which change the order of the displayed items. For example, if I don't modify the exposed filter, my view displays:
A
B
C

Select the second item in the list ('B'), no worries.

If I modify the filter to show:
A
B

Select the second item in the list ('B'), no worries.

However, if I select a filter that only exposes the following:
B
C

And select the first item in the list ('B'), then the confirmation screen shows that I selected 'A'. It's almost like the non filtered result is cached somehow.

NOTE: Disabling 'Authcache' causes the issue to go away. Moving to non-exposed filters is another work-around for our issue.

i only use memcached and cacherouter and so far there are no problem. could there be some conflict with one of the three caching modules you have there? would it be ok if you drop any one of them?

memcache has a 1mb cache limit so adjusting max_allowed_packet is not the "correct" fix. This needs to be handled in VBO code to make sure it doesn't push anything over 1 MB in size.

@mikeytown2: not sure which message you're replying to with #83.

In any case, this issue seems to be related to Form API storage being unable to handle more data than what can be stuffed in a single cache entry, which is itself dependent on the caching engine. This is IMO a deficiency in the Form API, but I'd rather work around it in VBO than target a fix in D8 core or beyond.

My current thinking is to minimize the form storage requirements to fix this issue, by recreating the necessary data at operation execution time instead of saving it all in form storage.

@infojunkie
reply was to the thread; not a single person; so I guess it was to you, as your "on top" of this issue. Call it my summary of the direction of a fix; and that direction is towards modifying VBO so it works with a smaller dataset.

What's the data structure look like & what do you actually need? Might be able to get away with some simple unset work.

BTW I find this code very helpful for outputting the contents of a variable.

echo str_replace('    ', '    ', nl2br(htmlentities(print_r($data, TRUE))));

@mikeytown2: Right now the function views_bulk_operations_form_submit stuffs too much information in $form_state['storage'], including the fully-loaded selected objects (via _views_bulk_operations_adjust_selection). That's what's causing the form storage to fail in caching environments.

The key would be to store the least amount of info needed to pass to _views_bulk_operations_execute.

Subscribing.

I've been futzing around with this tonight. Here's a bit of info, and I'm using Memcache (both for normal caching and sessions) with Pressflow. My VBO is batch API, dropdown select with submit, skip confirmation, merge single action's form with node selection view. I'm using it with nodes, where I select one node in the VBO, choose "modify node fields", head to the 2nd step form, change one field, and click Next.

In views_bulk_operations_form_validate(), I fall into VIEWS_BULK_OPS_STEP_VIEW of the switch. I'm failing here:

      if (!array_filter($form_state['values']['objects']['selection'])) { // If all 0, no row selected
        form_set_error('objects', t('No row selected. Please select one or more rows.'));
      }

Dumping out the $form_state shows that [values][objects][selection] has exactly 500 entries in the array (corresponding to the number of visible pager items in the view), but indeed they are all 0. So it bails and drops me the 'No row selected' error. So somewhere between the initial "Execute" of the modify node fields and the subsequent "Set parameters for Modify node fields" form, it's losing the selection.

I have no packet size issues showing up so I doubt that is the problem, at least for me.

Update: I can confirm that simply reducing the number of items in the view "fixes" the issue. I went down from 500 to 100 and now it's working. Strange.

Subscribing.

Wondering if any further progress has been made on this issue? I'm running a site with the following: Pressflow 6.22, CacheRouter 6.x-1.0-rc2, Memcache, APC, Varnish, Views 6.x-2.12, VBO 6.x-1.10.

When I'm attempting to bulk unpublish any amount of comments (can be as small as 2 or 3) I receive the "No row selected. Please select one or more rows." error message.

If someone could send a recipe to build the *simplest* caching scenario where VBO is guaranteed to fail, I'd gladly resume work on this.

@infojunkie, we have seen (and still have) the issue with two different caching configurations.

Re: The one I listed above: http://drupal.org/node/361871#comment-3912504. We had cacherouter setup to use the filesystem, but it was buggy when clearing cached information.

So, we switched to the memcache module:
Drupal 6.19
Views 6.x-2.11
VBO 6.x-1.10
Memcache API and Integration 6.x-1.9

And still see the problem.

NOTE: Because we require authentication to our site, we also have the following related modules, but I don't think they are necessary to expose the problem.
Authcache 6.x-1.x-dev
Block Cache Alter 6.x-1.4

Shot in the dark here, but I noticed I started getting max_allowed_packet errors with MySQL (no memcache enabled yet). The cause was the VBO module setting an *enormous* cache.

I idly wondered if enabling memcache so the cache goes there would mean I wouldn't need to change the MySQL config, but it was late so I left it.

So could this be memcache settings because the VBO cache gets *really* big and memcache can't handle it if it's not configured to expect such a huge chunk of data? Is there a memcache equivalent to max_allowed_packet?

Has anyone tried running memcache as memcached -vvv > /var/log/memcached.log 2>&1 and seeing what the log says when VBO fails?

Oh, and if my hunch leads anywhere then someone who is experiencing problems could try running memcache like this - there is an equivalent to max_allowed_packet:

/usr/bin/memcached -d -m 2048

-d = daemon mode
-m = memory allowed per object (64MB by default, that would set it to 2GB! Obviously only do that as a temporary test, to save messing about finding how much it needs to be to accommodate a bulging VBO cache object)

Subscribe.

Regarding #94 - Greg:
I am quite sure that your interpretation of the parameters is incorrect. -m defines simply the bin size, but not the maximum object size. To achieve higher object sizes you would have to change some source parameters and recompile.

In earlier parts of this thread (around #84), it did appear that the small bin size causes the form cached data to be lost.

Does VBO 6.x-1.x still store the full rows in form state? If yes, not doing that might help. Partially related: #1180538: Pass the selected views row(s) to the action.

@bojanz, VBO no longer does that in the latest D6 dev. However, it does store the Views style plugin object in the form, which contains the view, which contains the results :-(

And for the record, the command-line param you are looking for is:

-I            Override the size of each slab page. Adjusts max item size
              (default: 1mb, min: 1k, max: 128m)

FWIW, this is still happening with 6.x-1.x-dev 2011-Aug-12 module release and batch API (with or without performance maximization.) The error is "The selected nodes do not have any editable fields. Please select other nodes and try again." This despite having all fields selected in the VBO config page in the view. I also tried Queue API but the receive the same result. I can't easily test changes to memcache at the moment since this is a production site but I thought I'd at least report back on the latest version.

FWIW, changing from batch API to Drupal Queue and some additional testing seems to resolve this for me. I didn't fully try that last time before declaring it as non working.

Same issue and error like #101 with views_bulk_operations 6.x-1.11, no matter if using Batch API or Drupal Queue :-/ Running multiple memcached instances with -m 180. For me, the issue first appeared after upgrading from 6.x-1.10/6.x-1.x-dev to 6.x-1.11 about a week ago.

I did some quick tests and disabled the memcache module, which did not solve the problem for me. So I'm not entirely sure if caching is really the bottom of this. In case I'm experiencing a different problem, I opened another issue for the error message I'm encountering: #1296626: Select All (All Pages) is hopelessly broken.

...and maybe someone has a suggestion what to do in the "meantime"; if this issue has something to do with caching, it most certainly is not an option to disable caching for most of us; since the problem, at least for me, was introduced with views_bulk_operations 6.x-1.11 from 2011-Sep-21, I usually would try to downgrade; ironically, views_bulk_operations 6.x-1.10 from 2010-Oct-06 had a security issues, so probably it isn't a good idea to downgrade either. Am I missing an option, or is there actually no way out for an issue that couldn't be solved in the last 2.5 years (so hoping for a fix might not be a good idea, either)? Is there anything we can do to help debugging this?

Edit: #97 mentioned, that maybe "the small bin size causes the form cached data to be lost". Maybe someone is able to elaborate on this (e.g. what is a "small bin size"). I'm running servers with different memcached configurations (a legacy setup with six daemons and six memcache bins, and a newer setup with one daemon, both on Debian, one with "Lenny" and one with "Squeeze").

• The default configuration of ./etc/memcached.conf comes with a cap of 64 megs of memory. This is configured with the option -m ("according to the man page: Use <num> MB memory max to use for object storage"; default is -m 64)
• On the one-daemon-setup, I'm running memcached with -m 512 (not really a "small" bin size, right?)
• On the legacy setup, each daemon starts with -m 180

The legacy setup with six daemons/ six bins à 180 MB:

  'memcache_bins' => array(
    'cache' => 'default',
    'cache_block' => 'block',
    'cache_content' => 'content',
    'cache_filter' => 'filter',
    'cache_form' => 'form',
    'cache_menu' => 'menu',
    'cache_page' => 'page',
    'cache_update' => 'update',
    'cache_views' => 'views',
  ),

(8 bins à 180 MB ~ 1.1 GB memory for bins total)

The newer setup with one daemon/one bin à 512 MB:

  'memcache_bins' => array(
    'cache' => 'default',
  ),

The VBO error shows up on sites with both setups, so this would indicate that it doesn't matter if the minimal bin size is 180 or 512 MB, or the total memory size for all memcache instances is 512, or 1080 MB. I don't know if any of this qualifies as "small bin size", but I'm not too sure in the suggested correlation actually exists.

Other observations: #88 suggests that "simply reducing the number of items in the view "fixes" the issue. I went down from 500 to 100 and now it's working." Not sure to what "number of items in the view" referrs; I'm using e.g. "15" items per VBO page in the Views basic settings, and reducing that even more (e.g. to "5") does not fix the issue for me.

However, if I narrow down the total amount of items returned by the view (with a filter on something like node creation date "now -30 days) and use the dropdown selector "All (this page)", then I get to the field edit screen. Though, when using the "All (all pages)" dropdown selector, I'm getting the "no rows selected"/"selected items have no editable fields" errors. This is really interesting because the filter returns a total of 11 items, and the View pages after 15 items. So "All (this page)" and "All (all pages)" should operate on exactly the same 11 items, but it does not. Since the new dropdown selectors were introduced with 6.x-1.11 and I didn't encounter the issue with 6.x-1.10, my guesstimate would be that the item selection logic behind the "All (all pages)" dropdown selector is flawed.

So at least in my case and for some not too large bulk operations, the "workaround" is the opposite to #88: Increase the number of items the View returns per page (e.g. to "250", to avoid paging), then use the "All (this page)" dropdown selector. This seems to work, at least with a limited number of items to process (like "250").

To No. 77: I had been having the same problem, unable to delete 100 nodes per page. I set the number of nodes to 175, then I selected all on the page, then went to unpublish the nodes. I was asked for confirmation, said yes, and it worked. I then went back to admin/content/node and filtered on unpublished nodes (of a specific type -- feed item). Got all 175, selected all, asked to delete. Screen came back telling me 175 would be deleted, but there was no listing of those that would be so affected. Clicked ok, and they were then deleted successfully. Hope this help you diagnose the problem. PS: My caching is set to one minute.

Followup: This solution did not last, as I could not replicate it.

For those testing with 6.x-1.11, can you retest with 6.x-1.x-dev?
6.x-1.11 got released with a db_placeholders() bug that is responsible for some of the problems reported in this queue ("no editable fields" error, etc), so let's try to eliminate them first before tackling the others.

That said, I'm very sceptic about how we can solve this. VBO for D6 passes too much data around, but making it pass less data would break contrib modules that rely on having all that data. Plus, the D6 version is basically "finished", the only reason it's getting commits now is because releasing 6.x-1.11 filled up the issue queue with bug reports...

Hello, I have restarted with 6.x-1.x-dev (uninstalled the other version) and am having the same problems. With only 50 nodes selected to delete, I get the "0 rows" error. If I select 50, then unselect a few, then I can unpublish those, and then can go back and delete them. Seems I cannot delete any en masse. This module was working great until the SQL injection warning. Hope you can figure it out. Thanks

I am closing this issue.
As someone said, it is 2.5 years old, and describes 15 different problems. Too much history and conflicting information.

I've investigated the D6 code, and came to the conclusion that the "Select All (All Pages)" code is completely broken, which is why you're having problems.
There might be other ways to get broken selection as well, but trying to use Select All (All Pages) seems to cause most reports.
So let's continue that in #1296626: Select All (All Pages) is hopelessly broken.

Quoting myself from that issue:

The problem will be fixing it, since the post-6.x-1.10 code introduced the new complex handling of preserving selection, and select all, etc...
This is code that I'm just not familiar with.