[wp-trac] [WordPress Trac] #63480: UI refresh inconsistency in plugin deactivation flow (WP 6.8.1)
WordPress Trac
noreply at wordpress.org
Sun May 25 05:03:31 UTC 2025
#63480: UI refresh inconsistency in plugin deactivation flow (WP 6.8.1)
-----------------------------------+-----------------------------
Reporter: shandsadvertising2025 | Owner: (none)
Type: defect (bug) | Status: new
Priority: normal | Milestone: Awaiting Review
Component: Administration | Version: 6.8
Severity: normal | Keywords:
Focuses: |
-----------------------------------+-----------------------------
# WordPress Core Submission: UI Refresh Inconsistency on Plugin
Deactivation
**Issue:**
Plugin deactivation completes successfully, but the WordPress Plugins
admin UI (in `/wp-admin/plugins.php`) sometimes fails to reflect the
change immediately. This gives the false impression that the plugin is
still active until the user refreshes the page manually.
---
## Steps to Reproduce
1. Install and activate any minimal plugin (e.g. one that logs
activation/deactivation, with no UI or output).
2. Go to **Plugins > Installed Plugins**.
3. Click **Deactivate** on the plugin.
4. Observe that:
- The plugin shows as still “active.”
- No admin notice or visual confirmation appears.
- Manually refreshing the page reveals that the plugin has actually
been deactivated.
---
## What Actually Happens
- WordPress deactivates the plugin on the server.
- Files are unloaded correctly.
- However, the plugin still appears as active until the admin manually
reloads the page.
---
## What Should Happen
- The plugin row should update visually on deactivation.
- The admin should see a success message (as is done for activation).
- No manual refresh should be required.
---
## Technical Root Cause
In `wp-admin/plugins.php` (WordPress 6.8.1), the following code
immediately strips query args used to communicate plugin status:
```php
$query_args_to_remove = array(
'error', 'deleted', 'activate', 'activate-multi',
'deactivate', 'deactivate-multi', ...
);
$_SERVER['REQUEST_URI'] = remove_query_arg($query_args_to_remove,
$_SERVER['REQUEST_URI']);
```
If:
- A JS conflict delays DOM updates, or
- A slow server stalls table refresh, or
- An enhancement plugin overrides plugin rows…
…then the deactivation state is not rendered accurately.
---
## Suggested Fixes
- Delay removal of deactivation-related query args until **after** the
plugin table is rendered.
- Alternatively, introduce a JS-triggered refresh or force UI update of
the plugin row.
---
## Environment
- WordPress 6.8.1 (en_GB)
- Tested in Chrome, Firefox, Edge
- No JS console errors
- Site includes common plugins like ASE, WP Consent API, and Site Kit by
Google
- Tested with a custom debug plugin logging lifecycle actions
---
## Conclusion
This issue creates a confusing admin experience. Although technically
harmless, it erodes confidence in plugin lifecycle actions. The issue is
reproducible and verifiable, and we hope it can be resolved with a minor
core tweak.
--
Ticket URL: <https://core.trac.wordpress.org/ticket/63480>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform
More information about the wp-trac
mailing list