UI refresh inconsistency in plugin deactivation flow (WP 6.8.1)

[shandsadvertising2025]

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

[shandsadvertising2025]

this is the plugin that has debugging anable. your server will need to matche these settings

[avinashbhosale]

Reproduction Report

Description

This report validates that the issue is not reproduced.

Environment

• WordPress: 6.8.1
• PHP: 8.2.27
• Server: nginx/1.26.1
• Database: mysqli (Server: 8.0.35 / Client: mysqlnd 8.2.27)
• Browser: Chrome 137.0.0.0
• OS: Windows 10/11
• Theme: Twenty Twenty-Five 1.2
• MU Plugins: None activated
• Plugins:
  • Admin and Site Enhancements (ASE) 7.8.12
  • Site Kit by Google 1.153.0
  • Test Reports 1.2.0
  • WP Consent API 1.0.8

Actual Results

1. ❌ Error condition does not occur. Unable to reproduce the issues

Additional Notes

• The UI is refreshed automatically, can see the activation and deactivation messages whenever I activate/deactivate a plugin. I do not have to manually refresh the page.

Attachment:

video - https://core.trac.wordpress.org/attachment/ticket/63480/63480_UI_Refreshes_Automatically.mp4

[avinashbhosale]

Ui refreshes automatically after activating/deactivating the plugins

[krupajnanda]

Hello and welcome @shandsadvertising2025 👋

Thank you for the first report for this issue! Please check my report below.

Reproduction Report

Description

This report validates that the issue can not be reproduced.

Environment

• WordPress: 6.8.1
• PHP: 8.2.0
• Server: Apache/2.4.54 (Unix) OpenSSL/1.0.2u PHP/8.2.0 mod_wsgi/3.5 Python/2.7.18 mod_fastcgi/mod_fastcgi-SNAP-0910052141 mod_perl/2.0.11 Perl/v5.30.1
• Database: mysqli (Server: 5.7.39 / Client: mysqlnd 8.2.0)
• Browser: Chrome 136.0.0.0
• OS: macOS
• Theme: Twenty Twenty-Four 1.3
• MU Plugins: None activated
• Plugins:
  • Test Reports 1.2.0

Actual Results

1. ❌ Error condition does not occur(reproduced).

Supplemental Artifacts

Add as Attachment

---

Question About the ZIP File

I noticed the attached ZIP file in the ticket and was hoping to understand its intended usage. Could you please clarify how to best utilize to help reproduce the issue?

Request for environment configuration clarity

Can you please help confirm:

• If there’s any step or configuration I might have missed?
• Under what specific environment or condition the issue consistently occurs?

Happy to test again with more specific setup details!🙇‍♀️

[krupajnanda]

replication steps

[SirLouen]

@shandsadvertising2025 thanks for trying to report a potential issue

But as many testers have pointed out, unfortunately, this issue is not reproducible.

I've checked your plugin code, and it has some flaws. Firstly, the Uninstallation message is always being logged because it's not wrapped anywhere (unlike the installation message)
Second, the admin notice is weird. The condition will not trigger, unless you actually deactivate and reactivate the plugin within the 60-second expiry time happens. And it will say: Shands Meta Pixel was deactivated successfully when you have actually activated it…

For the rest, I can't really see anything wrong in the rest of the logging output. Plugin loaded message always run as expected, Activation logs on activation, deactivation runs on deactivation, and uninstall as I say, it's always running because of the wrong code logic. Long story short: it's not proving anything.

This said, unless you provide some code that actually triggers this behaviour, this is a clear worksforme candidate.

You can provide, any of these, if you like:

• A JS conflict delays DOM updates,
• A slow server stalls table refresh (I've tried step debugging and no problems here either).
• An enhancement plugin overrides plugin rows.

[karmatosed]

For now, I am going to progress this as a close with working. It has been tried to replicate and that hasn't been the case. Now, what might be able to happen is you provide more information and we can always reconsider. Until then moving this to cloes makes sense. Thank you everyone for your collaboration on this.