[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