Fix “Plugin could not be activated because it triggered a fatal error”

Checked 11 November 2026 · WordPress 7.1.4 · PHP 8.3.6 · MariaDB 10.11.14 · WP-CLI · Read time: 5 minutes

Case file

Symptom: Activating a plugin in wp-admin fails with the fatal-error message; the plugin stays inactive
Cause: The plugin file calls a function that does not exist, so loading it is a fatal error
Fix: Remove or fix the bad call in the plugin file, then activate again
Result: The plugin activates, and the homepage returns HTTP 200

The break · What you need · The diagnosis · The fix · Verify · If that didn’t work · What happened · Where this came from

The break

When a plugin is activated, WordPress loads its main file and runs its activation code. If that file has a fatal error — a call to a function that does not exist, a missing file it requires, a syntax mistake — WordPress refuses the activation and shows the message this guide is named for. The plugin stays inactive, and the site carries on without it.

This guide reproduces the break first. A disposable install had a test plugin whose main file called a function that does not exist. Activating it in wp-admin produced the message, and removing the bad call let it activate.

What you need

Access to the plugin files (SSH, SFTP, or your host file manager).
Access to wp-admin — unlike a theme parse error, the dashboard still works, because the broken code never loads.
A text editor that shows line numbers.

The diagnosis

1. Confirm the symptom

Activate the plugin in wp-admin and note the exact message. In the reproduction, the activation stopped with the message and the plugin stayed in the inactive list:

Output — wp-admin plugin activation

Plugin could not be activated because it triggered a fatal error.

Key result: the message appears in wp-admin, and the site itself never goes down. If the site is down too, the break is somewhere else — a plugin that is already active and fatal on every page load, not one that fails to activate.

2. Find the fatal error

Turn on WP_DEBUG and WP_DEBUG_LOG as described in the white screen guide, try the activation once, and read wp-content/debug.log. In the reproduction the log named the error plainly:

Output — wp-content/debug.log

PHP Fatal error:  Uncaught Error: Call to undefined function
srm_function_that_does_not_exist() in
.../wp-content/plugins/srm-fatal/srm-fatal.php on line 7

wp-admin shows the same error in a frame under the message, scraped from the failed activation — the file, the line, and the function that does not exist. Either way, the diagnosis is one line in one file.

One difference worth knowing: activating the same plugin with WP-CLI does not show the friendly message. It prints the raw stack trace instead, ending in the same thrown in .../srm-fatal.php on line 7. The message is a wp-admin behaviour, not a WP-CLI one — so check the error in wp-admin if the command-line output is hard to read.

Key result: the log gives the file, the line, and the missing function. That is enough to fix it — the plugin is calling something that is not there.

The fix

3. Remove the bad call

Open the plugin file the log names, go to the line it gives, and remove or fix the call. In the reproduction the plugin file called a function that did not exist on its seventh line; deleting that one line was the whole fix:

Code — the plugin file after the fix

<?php
/**
 * Plugin Name: SRM Fatal Test
 * Description: Test plugin that called an undefined function on load.
 * Version: 1.0
 */
// FIXED: removed the call to srm_function_that_does_not_exist().

If the call is supposed to exist — a function from another plugin that is deactivated, or a function the plugin itself should define — the fix is to restore what is missing rather than delete the call. A call to a function from a deactivated plugin means the plugin depends on that plugin; activate the dependency or remove the dependency from the code. A misspelled function name means the spelling is the fix. The log cannot tell you which of the three it is; the plugin’s own code can.

4. Activate again

Activate the plugin in wp-admin again. In the reproduction it activated at once:

Output — wp-admin plugin activation after the fix

Plugin activated.

Verify the site is back

Load the homepage and check the status code, and confirm the plugin is in the active list. In the reproduction the plugin showed active and the homepage returned HTTP 200. The test plugin was deactivated afterwards, leaving the install clean.

Step	Activation result	Homepage status
Plugin calls an undefined function	Plugin could not be activated because it triggered a fatal error.	HTTP 200
After removing the bad call	Plugin activated.	HTTP 200

If that didn’t work

If the error is in a file the plugin includes

The log names the file where the error happened, which is not always the plugin’s main file — it may be a file the main file includes, or a file from another plugin it depends on. Fix the file the log names, not the one you assume. If the file belongs to a different plugin, that plugin is the one that is broken or missing.

If it still fails after the fix

Re-upload a fresh copy of the plugin from its source — the plugin directory, or the author’s site — and try again. A file edited on the server can carry more than one mistake, and a clean copy removes all of them at once. The official common-errors guide gives the same advice for a related error, a call to an undefined function: try installing or upgrading the plugin manually, or deactivate the plugin that caused it.

What happened

A test plugin called a function that does not exist when its main file loaded, so WordPress refused to activate it and left it inactive. The debug log named the file and the line, the bad call was removed, and the plugin activated at once with the homepage at HTTP 200.

Where this came from

The message itself — “Plugin could not be activated because it triggered a fatal error” — is WordPress core, wp-admin/plugins.php, read in the installed 7.1.4 source and verified by activating through wp-admin.
A call to an undefined function meaning a plugin is looking for a file or function that is not there, and the fix of installing or upgrading the plugin manually, come from Common WordPress errors — WordPress.org.
What runs when a plugin activates — an activation routine set up with register_activation_hook() — comes from Activation / Deactivation Hooks — Plugin Handbook, Developer.WordPress.org.