2026年11月12日

WordPress Plugins Deactivating Themselves: Causes, Checks, Prevention

Errors & White Screen

This article is a localized edition of the Japanese original. Read the Japanese original

When a plugin has "somehow become inactive," there are only a few ways WordPress itself stops a plugin. In most cases, the file could not be found, a fatal error occurred during activation, the active_plugins value in the database was rewritten, or the plugin stopped itself because its requirements were not met. This article explains how to narrow down which cause applies and how to record "who, when and through which process" deactivated it the next time it happens.

First Check: Is It Really “Deactivated”?

Start by understanding the state accurately. Similar symptoms can have completely different causes.

It shows as "Inactive" in the plugin list: The plugin has been removed from the active_plugins option. This is the main subject of this article.
It shows as "Paused" in recovery mode: This comes from the fatal error protection feature in WordPress 5.2 and later, and it is different from deactivation. The plugin causing the problem is not loaded only while an administrator is logged in through the recovery mode link. Regular visitors keep seeing the "critical error" screen, so you need to decide whether to fix the plugin or deactivate it.
It is active but does not work: This is not deactivation; it is a cache, conflict or settings problem.

If a notice at the top of the plugin list says, in effect, that the plugin was deactivated because its file does not exist, the cause is "The File Cannot Be Found" in the next section. If you can use WP-CLI, you can check the currently active plugins directly.

wp plugin list --status=active
wp option get active_plugins --format=json

The Main Ways WordPress Stops a Plugin

The File Cannot Be Found

When you open the plugin list in the admin, WordPress uses validate_active_plugins() to check that the files of active plugins actually exist, and deactivates any it cannot find. This happens in situations such as these:

An automatic or manual plugin update failed partway, and the folder disappeared or its contents are incomplete
The folder was renamed via FTP or a file manager (including when someone followed a troubleshooting step that renames the whole plugins folder)
Part of wp-content/plugins was not restored after a server migration or backup restore
A security product or a hosting company's scan quarantined a file it flagged as malware

Deactivation through this path happens "silently," and the deactivated_plugin hook described later does not run. Keep this in mind when you set up logging.

A Fatal Error Occurred at Activation

If a PHP fatal error (Fatal error) occurs the moment you activate a plugin, WordPress cancels the activation. Even though it looks as if the plugin was "deactivated on its own," in this case it was never active in the first place. Typical causes are a PHP version that does not meet the requirements, a missing library or extension the plugin depends on, or a function or class name that collides with another plugin. If your site does not meet the required PHP version written in the plugin's header, you cannot activate it at all.

The Plugin Stopped Itself

Many plugins check the PHP version and required plugins (for a WooCommerce extension, WooCommerce itself) when they load, and stop themselves with deactivate_plugins() if the conditions are not met. This tends to happen right after a change such as the PHP version changing on the server or a required plugin being deactivated first.

The Database Value Changed

The list of active plugins is stored in active_plugins in the wp_options table (for network activation on multisite, in active_sitewide_plugins in wp_sitemeta). The list changes with operations such as restoring an old database backup, overwriting only the database from a staging environment, or editing the value directly with SQL and breaking the serialized format. If you use a persistent object cache such as Redis, the screen may not change even after you fix the database directly, so after fixing it, clear the cache with wp cache flush before checking.

Deactivation by the Host or Operations Tools

Some managed hosting providers automatically deactivate plugins they do not allow. Tools that manage multiple sites at once, or WP-CLI scripts run by the people operating the site, may also be deactivating them. Human actions are hard to identify without records, so the logging in the next section helps.

Steps to Narrow Down the Cause

1. Enable the Error Log

To find out whether a fatal error is involved, enable the debug log in wp-config.php. Back up wp-config.php before editing it.

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );

Errors are recorded in wp-content/debug.log. When you are done investigating, revert the settings and delete the log file. The log contains information such as file paths on the server, and it is dangerous if it can be read directly from a URL. Also check the server's PHP error log (often available in your hosting control panel).

2. Check the State of the Files

Check that the plugin's folder exists in wp-content/plugins/ and that its main PHP file is present. For plugins distributed on WordPress.org, you can compare the files against the official checksums to detect tampering or missing files.

wp plugin verify-checksums plugin-slug

If there is a mismatch, the quickest fix is to reinstall the same version. If the file owner or permissions changed and PHP cannot read the files, you get the same symptom, so also check that the user who ran the update matches the user the web server runs as.

3. Activate It Again and Watch What Happens

Try activating it on a staging environment if you have one, or otherwise at a time of low traffic. If it cannot be activated because of an error, the cause is in the "fatal error" family; if it activates but stops after a while, you can narrow it down to "the plugin itself," "a database rewrite" or "an outside operation."

An mu-plugin That Records Who Deactivated It

If it keeps happening and you cannot find the cause, record the moment of deactivation. Put the following file in wp-content/mu-plugins/ (create the folder if it does not exist). mu-plugins cannot be deactivated from the admin and are loaded before regular plugins, which makes them well suited to logging.

<?php
/**
 * Plugin Name: Plugin Deactivation Logger
 * Description: Logs plugin deactivations and changes to active_plugins to error_log.
 */

if ( ! defined( 'ABSPATH' ) ) {
	exit;
}

function pdl_context() {
	if ( defined( 'WP_CLI' ) && WP_CLI ) {
		return 'wp-cli';
	}
	if ( wp_doing_cron() ) {
		return 'cron';
	}
	if ( wp_doing_ajax() ) {
		return 'ajax';
	}
	return 'web';
}

// Normal deactivation (admin, WP-CLI, or the plugin's own deactivate_plugins())
add_action( 'deactivated_plugin', function ( $plugin, $network_wide ) {
	$user  = wp_get_current_user();
	$trace = wp_debug_backtrace_summary( null, 0, false );
	error_log( sprintf(
		'[plugin-deactivated] %s network=%s user=%s ctx=%s trace=%s',
		$plugin,
		$network_wide ? 'yes' : 'no',
		$user->exists() ? $user->user_login : '-',
		pdl_context(),
		implode( ' <- ', array_slice( $trace, 0, 10 ) )
	) );
}, 10, 2 );

// Log anything removed from active_plugins, including silent deactivations
add_action( 'update_option_active_plugins', function ( $old_value, $value ) {
	$removed = array_diff( (array) $old_value, (array) $value );
	if ( $removed ) {
		error_log( '[active_plugins] removed: ' . implode( ', ', $removed ) . ' ctx=' . pdl_context() );
	}
}, 10, 2 );

deactivated_plugin runs on normal deactivation, and the backtrace tells you which file's code deactivated the plugin. Deactivation because a file cannot be found does not go through this hook, so update_option_active_plugins also catches changes to the value. Conversely, if the table is rewritten directly with SQL, neither hook runs, so if nothing is recorded, suspect direct database operations or a backup restore. To track network activation on multisite, add the same logic to update_site_option_active_sitewide_plugins.

Operating Practices That Prevent Recurrence

Test updates on staging first: Especially before changing the PHP version or applying a major update, confirm that the plugin activates on a setup identical to production.
Decide the scope of automatic updates: One option is to turn off automatic updates for important plugins and update them manually at a time when you can check that everything works afterward.
Back up files and the database together: If you restore only one of them, active_plugins and the actual files get out of sync.
Move code that must not stop into an mu-plugin: Short pieces of code that are central to the site can be placed in mu-plugins, which cannot be deactivated, to limit the impact.
Check your host's policies: Banned plugins and how automatic scans work differ from company to company (as of October 2026, many companies still publish these on their help pages).

Summary

"Inactive" and "paused in recovery mode" are different. First, check the state accurately
WordPress stops a plugin almost always because of a missing file, a fatal error at activation, the plugin stopping itself, a database rewrite or an action by an outside tool
Use debug.log and a file check to tell error-related causes from file-related ones
If it keeps happening, log deactivated_plugin and update_option_active_plugins with an mu-plugin to identify who deactivated it and through which path
Test updates on staging, and back up files and the database together

Questions about WordPress? The publisher of this site is based in Japan and replies in Japanese. Contact (Japanese)