Features should be able to be deactivated from the Performance screen

[westonruter]

Feature Description

This was raised by @paaljoachim in a support topic:

I turned on many of the Performance Feature modules. I do not see any deactivate buttons though. How would I go about deactivating?

When we were implementing the Performance screen for standalone plugins I recall discussing whether there should be deactivate functionality, but it was ruled out. I didn't really understand why, so I'm opening this issue to discuss further. There was early discussion of adding a deactivate button at #651 (comment).

[felixarntz]

Worth noting that this was not raised as a problem in the survey from #1032 (comment).

To look at another reference: Does Jetpack allow deactivating the plugins for their features from their own UI?

[westonruter]

From the main Jetpack screen, apparently not. But they have a separate Modules screen that allows you to activate/deactivate modules, even in bulk:

[felixarntz]

I'd argue that modules screen is quite similar like the WordPress Plugins screen, in that it's far more granular in what it allows, so it makes sense.

But in the interest of keeping the main UI simple and focused, I think it makes sense not to include deactivation in that UI - similar to how Jetpack does it for its main UI. Basically making the common and intended actions intuitive and easily accessible, while making the "advanced" actions possible, but not at the cost of bloating the key interactions UI.

[westonruter]

The problem is that users don't necessarily know that the features are plugins. Therefore they don't know to go to the plugins screen to deactivate Performance features.

[paaljoachim]

I would say that in a UI when something can be enabled the user should also be able to disable it, or else in a sense I feel stuck not knowing how to disable the specific feature.

Use case.
I turn on everything to see if it improves a specific area. If I do not see any improvement then I would like the opportunity to disable.
One can do the same as the Jetpack screen and add the Deactivate button instead of a greyed out Active button.

[felixarntz]

@westonruter

The problem is that users don't necessarily know that the features are plugins. Therefore they don't know to go to the plugins screen to deactivate Performance features.

This is a fair concern. I wonder whether we can clarify that better in some way.

@paaljoachim

I would say that in a UI when something can be enabled the user should also be able to disable it, or else in a sense I feel stuck not knowing how to disable the specific feature.

Use case.
I turn on everything to see if it improves a specific area. If I do not see any improvement then I would like the opportunity to disable.
One can do the same as the Jetpack screen and add the Deactivate button instead of a greyed out Active button.

It depends. Jetpack does not show a deactivate button on its main features screen either. And even in WP Core, wp-admin/plugin-install.php, which uses similar UI as our screen, does not allow deactivating plugins.

Rather than overloading UI with additional abilities that are not key to the purpose of this screen, I think we should try to clarify where to manage those "features", e.g. clarify that they are technically plugins and can be managed in the "Plugins" screen as well.

[westonruter]

We could add a paragraph to the bottom saying something like:

Performance features are installed as plugins. To update features or remove them, manage them on the plugins screen.

Where the link goes to /wp-admin/plugins.php?s=WordPress%20Performance%20Team&plugin_status=all

The pre-populated search for "WordPress Performance Team" should usually result in only our PL plugins being listed, although it is possible for WordPress Performance Team to appear elsewhere:

Alternatively we could roll our own query parameter and filtering logic to only list out our plugins and their dependencies.

[felixarntz]

I think the approach to link with a search query like you said is definitely good enough. Implementing a custom query parameter IMO would be overkill.