Select All (All Pages) is hopelessly broken

Watchdog doesn't log anything like "The selected nodes do not have any editable fields", but when I edit the view I'm getting an error:

User warning: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near ') ORDER BY td.weight, td.name' at line 1 query: SELECT tn.vid AS node_vid, td.*, v.name as vocabulary FROM term_data td INNER JOIN term_node tn ON td.tid = tn.tid INNER JOIN vocabulary v ON v.vid = td.vid WHERE tn.vid IN (22200, 22197, 22198, 22199, 22196, 22195, 22107, 22106, 22109, 22110, 22111, 22114, 22112, 22116, 22113, 22115, 22117, 22118, 22120, 22121) AND td.vid IN () ORDER BY td.weight, td.name in _db_query() (line 148 of /var/www/drupal/includes/database.mysql.inc).

Not sure if this is related to the issue, and not sure either what is supposed to be the problem with the Views-generated query. Also, nothing relevant logged in the server's syslog about failures of memcache or APC.

To figure out if memcached and the Memcache integration module is involved in my problem, I disabled the 'Memcache' and 'Memcache Admin' modules, and removed the memcache servers and bins from settings.php, then did a 'drush cc' (all), and ran VBO again, with the same result; so judging from this quick test I am not sure if or to what degree Memcache is actually involved in the problem.

My settings for the memcached integration from settings.php:

$conf = array( 
  'cache_inc' => './sites/all/modules/memcache/memcache.inc', 
  'memcache_servers' => array( 
    'localhost:11211' => 'default', 
    'localhost:11212' => 'block', 
    'localhost:11213' => 'content',   
    'localhost:11214' => 'filter', 
    'localhost:11215' => 'form', 
    'localhost:11216' => 'menu', 
    'localhost:11217' => 'page', 
    'localhost:11218' => 'update', 
    'localhost:11219' => 'views', 
  ), 
  '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', 
  ), 
  'memcache_key_prefix' => 'mysite', 
);

Edit: On another site I'm experiencing the same issue when trying to run VBO operations on fields, but watchdog logs here a couple of messages/warnings:

Warning: implode() [<a href='function.implode'>function.implode</a>]: Invalid arguments passed in views_bulk_operations_fields_action_form() (line 103 of /var/www/drupal/sites/all/modules/views_bulk_operations/actions/fields.action.inc).
...
Warning: implode() [<a href='function.implode'>function.implode</a>]: Invalid arguments passed in db_placeholders() (line 275 of /var/www/drupal/includes/database.inc).
...
Warning: array_fill() [<a href='function.array-fill'>function.array-fill</a>]: Number of elements must be positive in db_placeholders() (line 275 of /var/www/drupal/includes/database.inc).
...
Warning: array_map() [<a href='function.array-map'>function.array-map</a>]: Argument #3 should be an array in views_bulk_operations_fields_action_form() (line 101 of /var/www/drupal/sites/all/modules/views_bulk_operations/actions/fields.action.inc).
...
Warning: array_fill() [<a href='function.array-fill'>function.array-fill</a>]: Number of elements must be positive in views_bulk_operations_fields_action_form() (line 101 of /var/www/drupal/sites/all/modules/views_bulk_operations/actions/fields.action.inc).

You might want to follow #361871: VBO loses selection with caching module.

I updated to 6.x-1.x-dev, ran update.php (no updates), and did a 'drush cc' (all). Issue still exists :-(

@Karim: Thanks a lot for your work! I did some preliminary tests with not too large data sets; so far

• I did not encounter any new regressions; e.g. "Select All (This Page)" still works. Good ;)
• I did not encounter the "Select All (All Pages)" bug with bulk modifications on fields or taxonomy terms anymore

I tried this with data sets of 25 and 150 records per page, spanning one or multiple pages. No problems whatsoever, seemingly as robust as 6.x-1.10.

This applies to views_bulk_operations 6.x-1.x-dev from 2011-Oct-13, as downloadable through 'drush' a couple of hurs ago. This dev release is a definitive improvement.

Again, thank you very much!!!

For me, the issue is back again in 6.x-1.13; on several sites, selecting anything across multiple pages does not work at all, anymore, again. As in the initial bug report against 6.x-1.11, operations like changing the content of fields does only work on one page.

All operations than span the complete result set lead to erratic operations; e.g. the changes are applied to some subset (8 out of 43 items), or to unselected items (!), and sometimes the operations summary does not match the records that have been altered.

As we suspected before, this might have to do with caching (core, APC, memcached, etc.; cf. #361871: VBO loses selection with caching module). All my sites are using this kind of caching, others might not and thus not encounter this issue. Additionally I'm running Views 3 on some of the sites (the inital report was against Views 2).

Currently, 6.x-1.13 must not be used in production environments without thourough prior testing, otherways results like described in #17 (or a lot worse) might happen.

The old workaround still applies: Don't run bulk operations across multiple pages of results; instead edit your View to show a larger result st (e.g. 50 instead of 25 items). If problems occur with bulk operations across the full result set, don't run any VBO on such large result sets.

We do not have a pure dev environment that could be accessed from outside (for obvious reasons); all our staging servers on the Internet have stuff like APC/Memcache enabled and can not be reconfigured easily without breaking something else.

However, the request ist absolutely reasonable, and I'll try to figure something out (might take a while). If someone is quicker, please stp up ;)

F'up to #555722: how to bulk assign taxonomy terms to nodes. Disabled the modules 'Memcache' and 'Memcache admin', and removed the relevant settings from settings.php on the sandbox site. Now I'm getting the "The selected nodes do not have any Content Taxonomy fields" error again when I try to run a "Modify content taxonomy terms" operation "across all pages".

If I select "Modify node taxonomy terms", make a selection for 822 items and click on "across all pages" and "Execute", I'm either getting "The selected nodes are not associated with any vocabulary", or (!!!) the announcement that VBO will process 25 (!!!) items. It seems to be erratic what happens (if/which error message is given, if/how many items are being processed, etc.).

@infojunkie: Please try to reproduce. VBO view is at ./admin/content/vbo, select "Nodetype = Ausgabe", and "Benutzer = knm". This should get a result set with 822 items. Then run on some taxonomy or field operation across all pages, from this point on I can not reproduce anything with some certainty. E.g. when trying "Modify node fields", I get a form with *all* defined fields (not just those available in the selected content type). When I edit an *exisiting* field and proceed, nothing is being processed; message: "No items were processed".

Question to the experts: If the 'Memcache' module is disabled as a module and in settings.php, is it really not used by Drupal/Pressflow if memcached is still active on the server???

@infojunkie: You are welcome - please take all the time you need - and many thanks for your helpfullness!

It'd be great if we could actually track down the nightmare issue #361871: VBO loses selection with caching module and this one (#1296626), or at least some parts of it ;)

Here are my test results for the current dev release.

Relevant settings:

• Use Batch API (checked)
• Preserve selection across pages (checked)
• Display processing result (checked)
• Skip confirmation step (not checked)
• The memcache integration module is enabled and configured in the site's settings.php; as recommended, I'm only using one memcache server and one bin ("default"). The memcached instance is started with a size of 1,024 (default is 64M) and, when the cache is warmed, it's filled to 80-90%.

Action: Modify node taxonomy terms

• Size of data set: 589 items, selection "across all pages"
• Observations during processing: Multiple times "PHP Fatal error: Maximum execution time of 30 seconds exceeded" in multiple locations, e.g. ./sites/all/modules/memcache/dmemcache.inc on line 41, ./sites/all/modules/views/includes/base.inc on line 71, ./sites/all/modules/views/includes/handlers.inc on line 31; ./sites/all/modules/views/includes/view.inc on line 1854, ./sites/all/modules/views/plugins/views_plugin_display_page.inc on lines 0 (!), 38, 57 and 938 et al.; Processing takes excessively long (>2.5 hrs)
• Overall result: Action is working properly; bulk operation successfully finalized; modifications were accomplished.

Action: Modify content taxonomy terms

• Size of data set: 829 items, selection "across all pages"
• Observations during processing: Again multiple times "PHP Fatal error: Maximum execution time of 30 seconds exceeded", multiple locations (as above) plus multiple "child pid 26667 exit signal Segmentation fault (11)"; Processing takes even more excessively long (>4.5 hrs)
• Overall result: Action is working properly; bulk operation successfully finalized; modifications were accomplished.

Action: Modify node fields

• Size of data set: 6,301 items, selection "across all pages"
• Observations during processing: Multiple times "PHP Fatal error: Maximum execution time of 30 seconds exceeded", multiple locations (as above) plus multiple "child pid 26667 exit signal Segmentation fault (11)"; Processing this one takes virtually forever (~10.5 hrs)
• Overall result: Overall result: Action is working properly; bulk operation successfully finalized; modifications were accomplished.

The numerous "PHP Fatal errors" in Apache's error log are ugly und pretty frightening; probably they indicate that something isn't right in multiple places, but I did neither notice a negative side effect (except a bloated error.log), nor were the errors actually "fatal" for the bulk operation.

I can not tell why processing these actions is so slow. I ran the tests on a server with Intel Xeon i7 W3520 and 24 GB of RAM; the average load without any running bulk operations is between 1.5 and 2.0, and even when processing large bulk operations it never exceeded 3.5. However, more important than speed is reliability, and regarding this the current dev code is an incredible improvement. With enabled memcache, I did not encounter the blank screen/WSOD I got a couple of days ago when processing the large 6k datase dataset, so I didn't file a issue in the memcache modules issue queue.

Unsystematically, I encountered that the "Modify node fields" action gave a screen with all fields available on the whole site; the correct behaviour is to only show the fields that can actually be edited according to the previous selection. However, this behaviour occured unsystmatically, not very often, and I can not provide a procedure to reproduce it. The workaround is to cancel the bulk operation and to re-apply the filter. A bit annoying, but no big dead, I think.

What still is not working properly: I can not select some items from a result set (by clicking on the checkbox) and apply the bulk operation selectively only to exactly those checked items. As in earlier versions of VBO, the bulk operation is applied to some unchecked items as well. However, it is *not* applied to all items of the result set, but I haven't yet figured out if there is a systematic offset. Also, selections across multiple page result sets still do not work at all for me, even if "Preserve selection across pages" is checked. As for now, this setting probably should be unchecked by default, as Manuel Garcia suggested in #29. I need to investigate the "Preserve selection across pages" issue further and start with an disabled mememcache integration again.

In a nutshell: For me, the current dev release is a huge improvement without regressions.

Of course, you can use is as long as you have the patience and energy.

I'm using 6.x-1.x-dev, and it is a lot more robust than the recommended release. At least for my use cases it does not have any side effects compared to 6.x-1.13. However, some smaller issues remain (some selective selects choose wrong items etc.), but this one can be considered fixed in 6.x-1.x-dev.

But: Shouldn't we keep this issue open until a new release with the fixes has been published??

Thanks for the new release, 6.x-1.14 runs pretty smoothly!