WordPress Plugin Keeps Deactivating After an Update? Check the Database

by

WordPress Plugins Keep Deactivating at 3 AM? Check the Database

There is a specific kind of WordPress problem that can waste an entire afternoon.

A plugin deactivates after an update. You reactivate it. Everything looks fine.

Then it deactivates again.

There may be no fatal error on screen. The site still loads normally for visitors. Your uptime monitor stays green. You reinstall the plugin, roll back the update, check the PHP version, increase the memory limit—and the problem keeps coming back.

At that point, it’s worth looking somewhere that often gets overlooked:

the database.

A damaged, outdated, or inconsistent plugin schema can cause a plugin to fail even while the rest of WordPress appears to be running normally. One issue worth investigating—especially on older, migrated, or restored WordPress installations—is a character set or collation mismatch.

But don’t start changing collations just because two tables don’t match.

First, prove that’s actually the problem.

What’s Actually Happening?

On the site that prompted this post, there were two root causes and all plugins were deactivating at 3 am not just one. This article goes through one issue with a specific plugin and another article deals with a different but similar issue.

In this specific case Rank Math Pro’s analytics tables were using utf8mb4_unicode_ci while the core tables they joined against were using utf8mb4_unicode_520_ci. The mismatch triggered an Action Scheduler cascade that rewrote the active_plugins option in wp_options — deactivating every plugin on the site, nightly, between 3 and 6 AM.

The debug log caught it only after a pre_update_option_active_plugins filter was added to trace what was writing to that option. After running ALTER TABLE ... CONVERT TO CHARACTER SET on the two Rank Math tables and deactivating Rank Math Pro, the plugins stayed active.

One other detail not to be underestimated… this issue was due to a lapsed Pro Subscription to Rank Math which prompted the plugin to stop updating and over time started causing these issues.

The license lapse is why the tables drifted and Canary Site Monitor tracking would have caught it.

WordPress plugins can create and maintain their own database tables. Plugins may also perform database or environment checks during activation, upgrades, or initialization.

If a plugin encounters something it doesn’t expect—a missing table, outdated schema, failed database query, incompatible column definition, or another requirement it depends on—it may abort initialization, throw an error, or, depending on how the plugin is written, deactivate itself.

The exact behavior is plugin-specific.

One database problem that can be particularly difficult to spot is a collation mismatch.

Collation determines how MySQL or MariaDB compares and sorts character data.

For example, an older WordPress installation might contain tables or columns using one of these:

utf8_general_ci
utf8mb4_general_ci
utf8mb4_unicode_ci
utf8mb4_unicode_520_ci

Having more than one collation in a database does not automatically mean something is broken.

That’s important.

MySQL can work with different collations, and simply discovering that a plugin table uses a different collation from wp_posts does not prove you’ve found the cause.

Problems can occur, however, when a query needs to compare character values with incompatible collations and MySQL cannot resolve the comparison.

That’s when you may see database errors such as an “illegal mix of collations.”

Why Does This Happen?

Mixed database schemas are especially worth investigating when:

  • A WordPress site has been migrated between hosting providers.
  • A database was restored onto a server running a different MySQL or MariaDB version.
  • The installation is old enough to have gone through the transition from legacy utf8/utf8mb3 to utf8mb4.
  • A migration or conversion only updated part of the database.
  • A plugin has been installed for years and has upgraded its schema multiple times.
  • A plugin update created a new table or column under different database defaults.
  • Tables were imported manually from another WordPress installation.

The important distinction is this:

Different collations are evidence to investigate—not evidence that you’ve found the problem.

Step 1: Capture the Actual Error

Before modifying the database, try to find out what WordPress or the plugin is actually complaining about.

If appropriate for your environment, temporarily enable WordPress debugging in wp-config.php:

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

Then reproduce the problem.

Reactivate the plugin, perform whatever action triggers the failure, and inspect:

wp-content/debug.log

Also check your PHP error log, web-server logs, hosting control panel, and any plugin-specific logs.

If this really is a collation problem, you want evidence pointing toward the affected database operation—not just a collection of tables that happen to use different collations.

Once you’ve captured what you need, don’t leave verbose debugging enabled indefinitely on production.

Step 2: Inspect the Database

You can get a high-level view of the collations used by your tables with:

SELECT TABLE_NAME, TABLE_COLLATION
FROM information_schema.TABLES
WHERE TABLE_SCHEMA = 'your_database_name'
ORDER BY TABLE_COLLATION, TABLE_NAME;

Replace:

your_database_name

with the actual database name.

This gives you a quick way to spot outliers.

Suppose most of the database uses:

utf8mb4_unicode_520_ci

while several tables belonging to the affected plugin use:

utf8mb4_general_ci

That’s worth investigating.

But it still doesn’t prove those tables are causing the failure.

Step 3: Look at the Columns

Table-level collation only tells part of the story.

Character columns can have their own character set and collation, so inspect those as well:

SELECT
    TABLE_NAME,
    COLUMN_NAME,
    CHARACTER_SET_NAME,
    COLLATION_NAME,
    COLUMN_TYPE
FROM information_schema.COLUMNS
WHERE TABLE_SCHEMA = 'your_database_name'
  AND COLLATION_NAME IS NOT NULL
ORDER BY TABLE_NAME, ORDINAL_POSITION;

This is often more useful than looking only at table defaults.

Pay particular attention to columns involved in the query that’s failing.

For example, if a plugin is comparing or joining a text column in one of its tables against a WordPress core table, compare the character set and collation of those specific columns.

That’s far more meaningful than simply trying to make every table in the database look the same.

Step 4: Back Up Before You Change Anything

If you’ve confirmed that a character set or collation problem is involved, stop before running ALTER TABLE.

Back up the database first.

Not:

“I have a backup from last week.”

Take one now.

And, ideally, confirm that you can restore it.

Character-set conversions can modify stored character data and column definitions. On a large or important production database, you want a reliable way back before making that change.

Whenever possible, reproduce the problem and test the repair on staging first.

Step 5: Determine the Correct Target

Don’t automatically change every plugin table to whatever you see on wp_posts.

wp_posts can be a useful reference, but the most common collation in the database is not automatically the correct target for every plugin table.

First determine:

  • What WordPress is configured to use.
  • What the affected plugin expects or officially supports.
  • Which columns are actually involved in the failing query.
  • Whether you’re changing only the collation or also the character set.

This matters because:

utf8mb4_general_ci

and:

utf8mb4_unicode_520_ci

use the same utf8mb4 character set but different collations.

That’s different from converting a legacy table from:

utf8

or utf8mb3 to:

utf8mb4

which can have additional storage and indexing implications.

Step 6: Make the Smallest Necessary Change

Once you’ve identified the actual problem and confirmed the correct target, you can convert an affected table.

For example:

ALTER TABLE wp_your_table
CONVERT TO CHARACTER SET utf8mb4
COLLATE utf8mb4_unicode_520_ci;

Do not copy that command blindly.

Replace:

wp_your_table

with the actual affected table, including the site’s real WordPress table prefix.

And replace:

utf8mb4_unicode_520_ci

with the character set and collation you’ve determined are appropriate for that installation and plugin.

Also understand what this command does.

CONVERT TO CHARACTER SET is not simply changing a label in MySQL’s metadata. It can convert character data and may change character-column definitions as part of the conversion.

Inspect the table definition before and after the operation.

A Few Things That Can Bite You

Indexed columns

If you’re changing character sets—for example, converting an older utf8/utf8mb3 table to utf8mb4—indexed character columns can encounter key-length or schema limitations.

That’s because utf8mb4 can require more bytes per character.

A collation-only change within utf8mb4 is different and shouldn’t automatically be treated as having the same byte-expansion problem.

Large tables

An ALTER TABLE operation can be expensive.

Depending on your MySQL/MariaDB version, table engine, schema, operation, and hosting environment, it can rebuild or lock a table and consume significant resources.

Don’t discover that for the first time on a busy production site.

Test first and plan accordingly.

Plugin tables

Be extremely cautious about advice that says:

“Just drop the plugin tables and reinstall it.”

Sometimes a plugin can recreate its schema.

Sometimes those tables contain years of data.

Forms, analytics, redirects, security logs, configuration, ecommerce data, indexes, custom records, or other information may live there.

Never drop a plugin table unless you’ve confirmed from the plugin’s documentation or code that it can safely be recreated and you’ve determined what data would be lost.

A database backup isn’t optional here.

Don’t Fix What Isn’t Broken

This may be the most important part of the entire process.

If you discover multiple collations in your WordPress database, resist the urge to “clean everything up.”

A mixed-collation database is not automatically a broken database.

Instead, trace the actual failure.

If the plugin is producing a database error, identify the query. Identify the tables and columns involved. Determine whether their character sets or collations are contributing to that error.

Then fix that problem.

Don’t normalize an entire production database simply because three tables look different.

Why This Is Worth Knowing

The frustrating part of this kind of failure isn’t necessarily the fix.

It’s the visibility.

Your homepage can return 200 OK.

Your uptime monitor can remain green.

Visitors can browse the site.

Meanwhile, a background plugin, integration, scheduled process, security tool, form handler, database operation, or other application component can be failing.

From the outside, the site is “up.”

Operationally, it isn’t completely healthy.

That’s the gap Canary Site Monitor is designed to help expose: the difference between a website that responds and a website that actually works.

Because sometimes the most expensive WordPress problems aren’t the ones that take the site down.

They’re the ones that quietly break while everything still looks green.

Leave a Comment