Opened 12 days ago
#49656 new defect (bug)
WP_Plugins_List_Table: redirects on core row actions when the current view is a custom view
Reported by: | pbiron | Owned by: | |
---|---|---|---|
Milestone: | Awaiting Review | Priority: | normal |
Severity: | normal | Version: | |
Component: | Plugins | Keywords: | |
Focuses: | administration | Cc: |
Description
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.