The "Bulk Actions" is not functioning correctly due to Plugin Dependencies feature

[Ankit K Gupta]

With the release of WordPress 6.5, if a plugin is required by another plugin, administrators are unable to use the 'Bulk Actions' feature for actions such as updating plugins, enabling/disabling auto-updates, deactivating/activating, etc. This is because the checkboxes for these plugins appear disabled.

Use Case:
For instance, consider a scenario where WooCommerce is installed on a site, along with other extensions like Booking, which require WooCommerce to be functional. If WooCommerce has an update available along with other plugins, and the administrator attempts to update all plugins using the 'Bulk Action' feature, the update process will exclude WooCommerce.
As a result, the 'Bulk Action' feature is ineffective for plugins that are required by other plugins.

Steps to Test:

1. Update the WordPress version to the latest 6.5 RC release.
2. Install WooCommerce and any other plugin that requires WooCommerce to function.
3. Navigate to the Plugins page in the WordPress Admin Dashboard.
4. Select all plugins using the Bulk Action feature.
5. Choose an action such as 'Enable auto-updates' from the Bulk Action dropdown menu.
6. Execute the selected action.
7. Notice that the action is not performed on the plugin that is required by any other plugin.

Demostration via Screencast:

• ​https://ibb.co/sFLz8sn
• ​https://somup.com/cZeUFhCOZC

[afragen]

This is actually expected behavior so the user is unable to use the bulk updater to do things they shouldn’t do to required plugins.

The team deactivated the Activate links, and other links as appropriate, when required plugin shouldn’t be activated but the only way to prevent this from happening via bulk updates was to prevent it from being checked.

[jorbin]

I wonder if the experience should be to remove the actions that aren't possible rather than prevent them from being in the bulk updates.

Moving to Future Release, but I could see this eventually going into either 6.6 or 6.5.1 (or being closed) based on the discussion.

[swissspidy]

I wonder if the experience should be to remove the actions that aren't possible rather than prevent them from being in the bulk updates.

Same. When doing bulk deactivation or deletion, plugins with dependencies could be skipped server-side when doing the bulk operation. But then that maybe requires some explanatory notice or so.

[azaozz]

As @afragen mentions above (and as far as I remember) the bulk actions were discussed several times, and the current behaviour was chosen as most appropriate/least confusing for the users.

remove the actions that aren't possible rather than prevent them from being in the bulk updates

When doing bulk deactivation or deletion, plugins with dependencies could be skipped server-side

Think this was one of the discussed solutions. Seems this may be more confusing/unexpected for the users. For example: selecting five plugins and doing a bulk action would update three and skip two. It is quite likely that the user will be unpleasantly surprised because two plugins were not updated.

Showing a notice to explain why these two plugins were skipped would be "after the fact", i.e. the user's expectations won't be fulfilled, and there will be an excuse/explanation after that failed (despite that WP "knows" that it will fail before the user attempts it).

For that reason the way this currently works is to "show & tell" the user that bulk actions are not possible before they attempt them, not show a failure notice after that.

I agree this behaviour can be refined and/or fine-tuned. Seems "future release" is the right choice here.

[knutsp]

This should be skipped server side, for now, since this is how bulk actions have always behaved and are expected to work - until something smarter is on the table.

There is already a "surprise" when activating already active plugins, and vice versa for deactivating
There is already a "surprise" when using the "Enable auto update" bulk action, since some plugins cannot be auto updated. Even when viewing not auto-updated plugins only, also those that can't be auto-updated are shown and all are se1ectable.

What I want is that all rows that can be bulk actioned on is initially selectable, but that this may change depending on which row action is wanted.

There are two ways to initialize bulk actions:

1. Select rows, then select action
2. Select action, then select rows

This can be utilized in my suggestion A:
Selecting action should trigger adjusting the checkbox visibility of each row. This means that the selectability for each row must be stored in the dom, possibly as a class for pure css changes. Or also the state of the checkbox for each row, enabling a warning message in case some selected rows get unselected after selecting or changing the action.

The view links come in pairs, active/inactive, auto-updated/not-auto-updated and so on. Top level generalized: is-something/not-is-something.

This can be extended in my suggestion B:
Enhance the views in a way to include active+deactivatable, active&not-deactivatable, inactive&activatable, inactive&not-activatable, auto-updated, not-autoupdated&auto-updatable and so on. To make this clear to user it will probably require two-level view links, a second level being visible only after selecting a top level view.