[wp-trac] [WordPress Trac] #63480: UI refresh inconsistency in plugin deactivation flow (WP 6.8.1)

[WordPress Trac]

#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:  Plugins                |     Version:  6.8
 Severity:  normal                 |  Resolution:
 Keywords:                         |     Focuses:  ui, administration
-----------------------------------+---------------------------------
Changes (by SergeyBiryukov):

 * focuses:   => ui, administration
 * component:  Administration => Plugins


Old description:

> # 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.

New description:

 # 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:

 {{{
 $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#comment:1>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform