I implemented the code in the patch, but maybe I'm missing something.
Using VBO on my Ubercart (D7U3) implementation, I am able to check an arbitrary number of orders and select the bulk operation (set order status) but then I get a confirmation screen that says:
You selected the following 2 items
-
-
(CONFIRM)
The item details are BLANK, but the operation is successful.
This happens *regardless* of whether email confirmation is checked or not.
The line that generates this confirmation is in:
views_bulk_operations.module
At:
line 677
As:
$output = theme('item_list', array('items' => $items, 'title' => t('You selected the following %count:', array('%count' => $count))));
The parent function is:
function theme_views_bulk_operations_confirmation($variables) {
Apparently, $variables does not contain the information the screen output command needs to identify the rows being affected.
Here's the .info file for the version of VBO I am running:
# cat views_bulk_operations.info
name = Views Bulk Operations
description = Provides a way of selecting multiple rows and applying operations to them.
dependencies[] = entity
dependencies[] = views (>=3.12)
package = Views
core = 7.x
php = 5.2.9
files[] = plugins/operation_types/base.class.php
files[] = views/views_bulk_operations_handler_field_operations.inc
; Information added by Drupal.org packaging script on 2022-10-19
version = "7.x-3.7"
core = "7.x"
project = "views_bulk_operations"
datestamp = "1666149180"
For the Apache 2 Web Server to be able to process PHP, the libapache2-mod-php Apache 2 Web Server Module must be installed along with the PHP Scripting Language Interpreter (php).
While the libapache2-mod-php Apache 2 Web Server Module sits within the Apache 2 Web Server operating environment and configuration files, it is not a product of the Apache 2 Web Server Project. Both libapache2-mod-php and php are actually products of the PHP Project.
The reason for the existence of libapache2-mod-php has to do with the way Apache used to deploy scripting languages like PHP, Perl, C and many others. In the old days, scripts were processed by way of something called the Common Gateway Interface (CGI) which involved: (A) Launching an external processing environment; (B) Loading an appropriate script interpreter into the processing environment; (C) submitting the script for processing; and, finally (D) Receiving the processed script result back. This methodology incurred significant and measurable time and space costs.
Seeking a way to make PHP faster, the PHP Project took advantage of the modular design of the Apache 2 Web Server by producing a custom Apache 2 Web Server Module called libapache2-mod-php that embeds PHP within Apache 2 Web Server operating environment, avoiding the need for external processing and making PHP significantly faster.