Plugin having dependent plugins not checkable for the bulk actions

[giuse]

Steps to reproduce the issue.

1) Install and activate a plugin with one or more dependent plugins. Let's call it Plugin A. Let's assume Plugin A has the slug plugin-a.

2) Install and activate a plugin that depends on plugin A. Let's call it Plugin B.
Plugin B has the following comment in the plugin header of the main file:

Requires Plugins: plugin-a

3) Disable Plugin B.

Then, in the list of plugins the checkbox of Plugin A is not checkable for the bulk actions even if Plugin B is disabled and Plugin A is active.
You can't do it if you want to bulk deactivate Plugins A and other plugins.

I agree you should not be able to delete Plugin A if Plugin B is still in the filesystem, but you should be able to bulk deactivate it with other plugins if Plugin B is inactive.

[afragen]

This is working as designed. Any dependent plugins must be deactivated before you can deactivate a dependency.

​https://make.wordpress.org/core/2024/03/05/introducing-plugin-dependencies-in-wordpress-6-5/

[giuse]

@afragen, in the link that you shared I see:

Bulk Actions are disabled for dependency plugins.

For me, you should delete that sentence, and consider this ticket.

Why should you disable bulk actions for dependency plugins if the dependent plugins are disabled? You should prevent the deletion if the dependent plugin is still in the filesystem, but not, for example, the update, activation, or deactivation.

Sorry, but you can't close a ticket just by linking a page where it's written that this is how it works. It should not work so.

Please, keep this ticket open, other users probably think like me too.

[afragen]

I’m sorry. You are correct. This is incorrect behavior the bulk activity checkbox should be enabled at the same time the dependency can be deactivated or deleted.

[Norm.Sash]

I absolutely agree with @giuse regarding this issue. Where I have seen the issue is when I disable a number of plugins, including a core plugin and its dependent plugin. Then I go to recently active and want to do a bulk select to reactivate the plugins.

In this case (current behavior) is that both the core plugin and the dependent plugin have their checkboxes greyed out (even though the core plugin can be activated). I understand the dependent plugin checkbox being greyed out, but the core plugin checkbox should not be greyed out (disabled).

[costdev]

Hi @giuse, thanks for opening this ticket!

Some historical context

The scale of the Plugin Dependencies feature means that we had to make decisions about deferring some aspects of it, such as this one, until a later release. Doing so gives us time to make sure those aspects are done right, and we made those decisions regrettably in the short term, knowing that it was better for users in the long term that we did things both correctly and incrementally.

The Bulk Actions checkbox for these plugins was intentionally disabled until such time as we can get some additional work done. In line with this, note that the deletion of a dependency (Plugin A in your example) via Bulk Actions was removed in [57620].

Where I stand

I fully agree that a smoother process is needed here for Bulk Actions. There are a number of actions available in the dropdown menu, and enabling the checkbox means any of those options may be selected. That's not inherently a problem, but it can lead to problems.

What kind of problem?

• Plugin A and Plugin B are both inactive.
• The user checks several plugins, including Plugin A, but not Plugin B, then selects Delete.
• Plugin A's deletion should fail.
• However, as long as Plugin A is installed, Plugin B's checkbox will be disabled, meaning it can never be checked at the same time as Plugin A, and therefore Plugin A can never be deleted by Bulk Action.
• Re-enabling Plugin B's checkbox means that even if both Plugin A's and Plugin B's checkboxes are checked, if Plugin B comes later alphabetically than Plugin A, then Plugin A's deletion will fail and the user will need to perform another Delete Bulk Action. Therefore, we'd only be partially resolving the issue in a way that makes the remaining case all the more frustrating for users.
• Now, expand the Delete example to also cover Activate and Deactivate.

What's the additional work?

We need an activation/deactivation/deletion order based on whether a plugin is a dependency, a dependent, or both. By having that order, we can re-enable the checkboxes for all of these kinds of situations. I plan to get this work done as soon as I can, with an aim of release in WordPress 6.7 so there's plenty of time for the work to be reviewed and tested thoroughly when it reaches that stage.

I fully appreciate that everyone (including me) wants to see this on a much shorter timeframe. Unfortunately, resources are stretched at this time and there aren't many people with domain awareness of this area. I'm mindful of the frustration this may cause, and I hope everyone understands that we're doing the absolute best we can to build on what we delivered in WordPress 6.5 as soon as possible.

---

Closing this ticket as maybelater would be incorrect, as the plan is for definitelylater, so I'm going to milestone this ticket for Future Release to note that it's been reviewed and that it should remain open until a later time. I'll also assign myself as the ticket's owner.