WordPress plugin cannot be deactivated: find what loads it

Identify what remains active before looking for a button

The plugin still seems to be loaded, but the Deactivate link is missing or unavailable. This behavior may be normal: another component depends on it, it is activated for the entire network, or its file is loaded as a must-use plugin. A feature still visible after deactivation may also come from a cache or another code provider.

The goal is to identify what is responsible for loading it, then use that mechanism’s removal procedure with a planned rollback. A missing button does not authorize deleting the plugin folder or modifying its activation list in the database. These workarounds may break components that rely on it.

On a self-hosted installation, procedures vary with your administration, network, and file permissions. On WordPress.com or a managed plan, some components belong to the platform. In multisite, an action may affect several subsites; check this scope before testing. A must-use plugin may also exist on a site that is not a network: the MU name alone does not imply multisite.

Preserve the function and prepare a copy for removal

Record the component’s name, author, version, and assumed location. Describe the function you want to remove or compare. If it sends messages, processes orders, or synchronizes data, perform tests on a copy with external effects disabled. An interface disappearing does not prove that scheduled tasks have stopped.

Keep an appropriate backup of settings and files, along with SFTP or file-manager access independent of the dashboard. For a personal file, keep a private copy outside the public directory, with its path and permissions. Do not treat a tool’s Download button as a backup of the entire installation.

Choose a reference visit that demonstrates the function without triggering an important action. Prepare how to restore the component: native reactivation, restoration of just the file, or a return through the owner’s panel. Deactivation, uninstallation, and data deletion are three different operations. Diagnosis generally does not require going as far as deletion.

Read the status on the correct screen with the correct account

Open Plugins, Installed Plugins and record the exact status. Examine the filters and row indicators: network activation, a required dependency, or the Must-Use category. Also check that the account actually has permission to manage this plugin. An author role or an account restricted by the platform cannot necessarily use the same actions as an authorized administrator.

The Drop-ins filter, if shown, indicates another category: special files placed directly in the content directory, normally wp-content. For example, object-cache.php and advanced-cache.php may belong to a caching system. They are not MU plugins. Their presence alone does not show that every function is active: some loading depends on conditions. Identify their owner and use its procedure; do not apply the MU removal process described later.

A component displayed under another name may load the function you are looking for. Therefore record the provider and file, not just the marketing text visible in a menu. If a deactivation link is missing after administration customization, compare with the responsible account without asking its owner to share credentials.

1. Open the site’s Plugins screen and record the relevant row.
2. Look at dependency and network activation notices.
3. Check the Must-Use filter separately if the component is not in the ordinary list.
4. Have the administrator confirm your permissions if the action is restricted.
5. Then choose the procedure matching the status, without moving a file yet.

Respect dependencies before deactivating the provider

WordPress may prevent deactivation of a plugin on which other active plugins depend. The row then identifies those dependent components. Fictional example: A provides a shared function and B uses it. Removing A while leaving B active risks leaving B without its provider; the interface may therefore prevent this operation.

This approach is appropriate if removing the dependent components is consistent with the test. On the copy, record their state, then first deactivate those that need the provider. Do not remove the dependency declaration from the plugin file to make the link clickable. Undeclared dependencies may also require documentation checks.

1. In Installed Plugins, read which components depend on the target plugin.
2. Check that their temporary removal is acceptable for the function being tested.
3. Deactivate them one at a time on the copy, noting the order.
4. Then deactivate the provider using its now-available link.
5. To restore the initial state, reactivate the provider before its dependents and check their functions.

Check why the Delete link is missing

In Plugins > Installed Plugins, locate the target plugin and record its row before changing anything. Distinguish three situations: the component is active, another installed plugin declares it required, or it appears under Must-Use. On multisite, also check whether management belongs to network administration. The same word “required” does not necessarily describe the same loading mechanism.

For a declared dependency, read the names of plugins using the provider. The Deactivate link may become available again once the dependents are no longer active. Deletion follows a different rule: an installed dependent may continue to block the Delete link even when inactive. Preserve files and settings before deciding on removal. Do not edit the plugin header to make the link appear.

If the component appears under Must-Use, instead record the entry file and owner of that loading mechanism. An inventory command can confirm its type. The decision to remove a host-managed file or shared loader belongs to the person maintaining that mechanism.

Follow provider and dependent actions on a copy

Proposed procedure on a copy: prepare a fictional provider A and a dependent B declaring it in its Requires Plugins header. Compare A’s row while B is active and after deactivating B. Distinguish the Deactivate link from the Delete link: an installed dependent may retain a deletion restriction. Record the messages actually displayed by your version before continuing.

To observe permanent removal, use only fictional components with no useful data and their native confirmation form. Then restore their reference files, activate the provider before the dependent, and verify that the reference function returns. This procedure describes an exercise to reproduce; it is not an evidence-backed test report.

Before repeating this process with your components, confirm which dependents can be removed and what each uninstallation deletes. The form may warn that data will be deleted. Keep the exact packages and a restorable backup of the affected data. If B must remain installed to preserve a function or allow its immediate return, keep its provider too. For simple diagnosis, stop after deactivation on the copy. If permanent removal is chosen, deactivate the dependents, then the provider, and remove only dependents whose deletion is planned. Reload the list and check that the block has disappeared before deleting the provider. If data was erased, reinstalling files is not enough to recover it.

Check the must-use file separately

For a third reference case, use only an identifiable personal PHP file in a copy’s must-use plugin directory. Record its presence under Must-Use and in the command-line inventory. Move only this file to a private folder after confirming its independence, then check the new request. Return it to its initial path and verify that its function returns. This is a proposed procedure to document in your environment.

To confirm the path, run the command below through the already-authorized terminal on the copy. Replace the fictional path and address. The file field helps distinguish the file that starts loading from a subfolder it includes. The command does not choose the file to remove or measure its dependencies. If the file is shared across a network, the subsite parameter selects the read context. Moving it would affect the installation sharing that file.

wp --path="/chemin/recette" --url="https://recette.example.test" plugin list --status=must-use --fields=name,status,file --skip-update-check --format=json

Restore components in the correct order

For an isolated personal must-use file, record its path, permissions, and expected marker before moving it. Check the control page and function on the next request. If the file is a loader including several components, first identify the mechanism intended by its owner. Moving the loader may remove several functions at once. To roll back, return the exact file to its original path, reload the screen, and check the observed effect. For ordinary plugins already deleted, restore the provider and dependent files, then activate them in that order and restore data if needed.

Use network administration for shared activation

A network-activated plugin is not controlled by an individual subsite’s deactivation button. This approach requires permission to manage network plugins. From My Sites, Network Admin, Plugins, find the row and its shared status. If this menu is absent from your account, the network administrator must perform the comparison.

Network deactivation may affect several subsites and their dependencies. Prepare a network copy or an authorized test scope, and record usage before acting. After removing shared activation, still check the status specific to each affected subsite; do not infer from one screen that every loading mechanism has disappeared.

1. Record the sites and components using the network plugin.
2. In Network Admin, Plugins, choose its network deactivation only within the prepared scope.
3. Check a new request and the reference subsite’s status.
4. If the test must be undone, restore the initial network activation.
5. Check shared functions and local states before considering the rollback complete.

Take an inventory with WP-CLI if that access already exists

With SSH and WP-CLI already available, the commands below request an inventory without deactivation. Replace the fictional path with the actual WordPress root. The three lines distinguish must-use plugins, network activations, and drop-ins. On multisite, add --url='https://sous-site.exemple.invalid' to each command, replacing this fictional address with the relevant subsite’s address. This parameter selects the context without limiting the scope of a shared file. Keep the record private.

Starting WordPress may load installation code; prefer the copy during diagnosis. The update check is avoided here with --skip-update-check. If the site cannot start, an inventory command may also fail. Do not multiply production attempts just to obtain a list.

A different status sometimes explains why two tools display seemingly contradictory states. The --skip-plugins option leaves MU plugins loaded: it does not deactivate them. The inventory helps identify who owns removal; it does not replace confirmation of dependencies or network scope.

wp --path='/chemin/wordpress' plugin list --status=must-use --fields=name,status,version --skip-update-check
wp --path='/chemin/wordpress' plugin list --status=active-network --fields=name,status,version --skip-update-check
wp --path='/chemin/wordpress' plugin list --status=dropin --fields=name,status,version --skip-update-check

Identify the must-use file and its owner

MU plugins normally reside in wp-content/mu-plugins. Configuration can customize the path; consult the existing WPMU_PLUGIN_DIR value if necessary without changing it to bypass loading. WordPress loads PHP files placed directly in this directory. An internal folder is not automatically a standalone component: a small root-level file may explicitly load it.

With SFTP or the file manager, open a copy of the file read-only. Record its header, comments, and loading statements. Look for its owner: personal code, an agency, a host, or a tool generating it. A generically named file may load several functions; removing it may have a much broader effect than the name displayed in administration suggests.

If the file belongs to the provider or performs a platform function, use its management mechanism. If its origin is unknown, have it identified before removing it. Being must-use in the technical sense proves neither that it is dangerous nor that it is unnecessary. This step should yield a precise path, an owner, and a known loading scope.

Remove a confirmed personal file without a new plugin

This approach is suitable for a personal MU plugin whose owner confirms its independence, on a prepared copy. It requires file access that allows recovery even if WordPress stops starting. Keep the original file and its permissions in a private location outside the public directory. Do not simply rename its extension while leaving a code copy potentially readable from the web.

Targeted removal applies to the identified entry file, not the entire must-use plugin directory. If other files directly load this code, simply moving it may produce a loading error; this dependency must be checked before testing. Prepare to return it to its exact path.

1. Verify the actual path and the private copy of the confirmed file.
2. Move only this entry file to the prepared private location.
3. Open a new request on the copy and observe the reference function.
4. Also check neighboring functions and the PHP log.
5. To undo the change, return the same file to its path with its initial permissions, then verify recovery.

Do not break a loader that brings several components together

A file containing just a few lines may be a loader: it includes other files or a library directory. Removing an internal file without adjusting the loader may cause a fatal error. Conversely, moving the entire loader may deactivate several functions when you intended to compare only one.

Once this mechanism is identified, have its owner isolate the intended function. On the copy, the owner can use the planned setting or prepare a targeted loader change, preserving its initial version and performing an appropriate syntax check. There is no universal line to comment out without reading the actual dependencies.

Do not move all of mu-plugins to obtain an empty site, or copy that directory into the ordinary plugins directory hoping to regain a button. Activation mechanisms and loading order differ. If a file returns after removal, a deployment task or management tool may be recreating it. Identify that owner instead of deleting the same copy at every startup.

Use Mu Manager only on a suitable private copy

Mu Manager, by Jose Mortellaro, can add management actions to the must-use plugin list. This assistance remains optional and does not determine whether a file can be removed without breaking other functions. Check its current requirements on its listing before adding it. On a network, only the person responsible for the shared scope should use this variant: the file is shared even if a local screen exposes an action.

Its deactivation code replaces the .php suffix with .disabled- followed by an identifier in the same directory. Reserve this variant for a private copy with protected file access and a personal file containing no secrets. Without that guarantee, prefer manually moving it outside the public directory. The tool may also create index.php and an auxiliary mu-manager.php file maintaining list access; their presence does not prove that the old component is still loaded.

Renaming requires WordPress to be able to write directly into this directory. If the action changes nothing, check the file and its status, then return to SFTP or the provider. Do not broaden permissions to force the tool to work. Reactivation must restore the exact PHP name; if administration stops responding, use the preserved private copy to restore only this file to its initial path.

1. Check compatibility, the backup, and protection of the copy before installing the official plugin.
2. Open Plugins, Installed Plugins, then Must-Use.
3. Note its exact filename, then choose Deactivate on the confirmed personal file’s row.
4. Check the rename and function in a new request, without using Delete or modifying code in the editor.
5. Return through Activate on that same row before deactivating the management tool if you are undoing the test.

Handle platform-managed files at their source

A host or agency may install an MU plugin for caching, updates, login, or platform-specific behavior. A file-management interface does not establish that you can remove this integration without consequences. The component may be reinstalled automatically or expected by other services.

Give the administrator the exact path, name, function to compare, and expected result. Ask for the intended suspension mechanism for that function alone, or for a diagnostic copy compatible with the platform. Panel-based deactivation, if available, must be documented with its initial value and scope. You do not need to erase the managed-file directory to prove that its files are active.

If the function must remain enabled on that plan, adapt diagnosis to this constraint. A test on a copy stripped of every platform integration does not necessarily represent production. Note that difference before attributing success to removal of an ordinary plugin. The goal is to control the right mechanism, not to manufacture an empty plugin list.

Check loading and the function in a new request

After targeted removal, open a new request on the copy. An already-started process or a cached page may show an old state. Check the native status or appropriate inventory, then the reference function. A name simply disappearing from a list does not guarantee that another file no longer includes the same code.

If the function remains visible, compare the theme, other plugins, and identified loader. It may be supplied by several components or by a retained output copy. Do not continue deleting files to force the expected result. Return to evidence connecting the behavior to a specific loading mechanism, with a log from the same time.

Then check administration, a public page, and neighboring functions. On a network, add a second subsite affected by the shared action. If a loading error or function loss appears, immediately return the file or restore the intended activation. A comparison is conclusive only if the rest of the necessary context remains consistent and the result can be reproduced after rollback.

Restore the intended state and document the owner

At the end of diagnosis, restore each item according to the approach used: provider before dependents, network activation at its initial level, or a personal file at its exact path. With a tool that renamed the file, use its reactivation action before removing the tool. Check the function after rollback instead of relying only on a notification.

If removal is to become permanent, have uninstallation and data handling prepared separately. A must-use component does not necessarily execute the same mechanisms as a normally activated plugin. Tasks, settings, or data it created may require their own procedure. Do not delete them on the assumption that all are now unnecessary.

Keep the entry path, owner, dependent components, network scope, and authorized suspension method. This record explains why a button may be missing and prevents the same workaround during the next incident. A lasting result is a consciously removed or retained function, with an identified loading mechanism and controlled rollback, without blindly deleting directories to simplify a dashboard.

Decide on removal based on the loading type

For diagnosis, stop at the first reversible removal that permits comparison. An ordinary plugin is deactivated from its row; a provider waits for its active dependents to be removed; network activation belongs to the network administrator. A personal MU file requires identifying its loader, while a drop-in requires its owner’s procedure.

Before comparing, record precise visible evidence: a menu, a loaded resource, or diagnostic output containing no sensitive data. After removal, examine a new request and its log. If the function persists, look for a second provider or cached response before moving another file. On rollback, the evidence should reappear with the same settings, without unnecessarily reactivating components that were inactive before the test.

Mu Manager remains an optional alternative for a personal file on a private copy. Manually moving it outside the public directory avoids leaving a renamed copy of code accessible to the web server. For a beginner without independent file access, help from the hosting owner is more appropriate than adding a file manager inside WordPress during the failure.