WP_Plugins_List_Table: redirects on core row actions when the current view is a custom view

[pbiron]

WP_Plugins_List_Table::__construct() sets a global variable to the current value of the plugin_status query arg. That global is used in the URLs of the row action links ('activate', 'deactivate', etc) core adds, so that when a user clicks any of those links the user is returned to same view they were on.

Like all good list tables, WP_Plugins_List_Table allows custom views to be added (with the views_plugins and views_plugins-network filters).

The problem is that the list table constructor sets the global variable to 'all' if plugin_status query arg is for a custom one.

Hence, when the current view is a custom view, then the core row actions take the user back to 'all', which is a bad UX in that he behavior of core's row actions is different depending on whether the current view is built-in to core or is custom.

This came up recently in ​an issue opened against the ​WordPress Auto-updates Feature plugin.

That specific issue will resolve itself when the feature plugin is merged in core because the plugin_status for the 2 views it adds will be added to the whitelist in the constructor. But the problem will still exist for any other plugins that add custom views to that list table.

WP_MS_Themes_List_Table::__construct() also sets a global that is whitelisted to the statuses that core knows about. However, that is not a problem because it doesn't use that global to add a query arg to the row action links: the redirects on the row actions are handled differently.

I think the easiest way to address this would be modify WP_Plugins_List_Table (and wp-admin/plugins.php) to handle the redirects on core row actions actions the same way that WP_MS_Themes_List_Table does.

[nikunj8866]

Reproduction Report

Description

❌ This report validates that the issue cannot be reproduced.

Environment

• WordPress: 6.9-alpha-60093-src
• PHP: 8.2.28
• Server: nginx/1.29.0
• Database: mysqli (Server: 8.4.5 / Client: mysqlnd 8.2.28)
• Browser: Chrome 140.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Test jQuery Updates 3.0.2
  • Test Reports 1.2.0

Steps to Reproduce

1. Navigate to the Plugins screen.
2. Select the Auto-updates Disabled custom view tab.
3. From this tab, deactivate a plugin.
4. Observe the redirect after the deactivation.

Actual Results

1. ❌ The reported issue could not be reproduced.
2. ✅ The plugin deactivates successfully. After deactivation, the user remains in the Auto-updates Disabled tab.

Additional Notes

Reproduction steps were followed from the reference issue: ​https://github.com/audrasjb/wp-autoupdates/issues/49#issuecomment-599006968.

Supplemental Artifacts

Screen recording: ​https://www.awesomescreenshot.com/video/44090674?key=ba4b35143e936bf1740691258653fa4f

[swissspidy]

Removing milestone from closed ticket.