Skip to content
Website Rescue Rescue

Plugin Errors

WordPress Plugin Causes Critical Error

Intermediate Risk: medium

Last reviewed

Hosting access may not be needed Database access usually not needed

Graphic options · pick what to keep

decisionTree

statusBadge

serverRack

requestTimeline

Direct answer

A plugin is triggering a PHP fatal error during WordPress bootstrap. Use the recovery-mode email, disable the named plugin in wp-admin, or rename its folder under wp-content/plugins via FTP—then update, roll back, or replace that plugin before reactivating it.

When a specific plugin causes “There has been a critical error on this website,” WordPress is catching a fatal from that plugin’s PHP on load. Your database content is intact—the priority is stopping that plugin from running. This guide covers recovery mode, log-based identification, safe deactivation, and fixing or replacing the plugin without breaking the rest of the stack.

Intermediate

What the error means

Plugins hook into nearly every WordPress request from wp-content/plugins/plugin-slug/. If their code throws an uncaught fatal—after an update, bad settings import, PHP version change, or conflict with another extension—WordPress 5.2+ shows the critical-error screen and may email the admin a recovery link that pauses the faulty plugin for your session. The site stays broken for other visitors until the plugin is deactivated or fixed. Must-use plugins and drop-ins can fatally load even when regular plugins are disabled, so logs matter. This is not a generic “WordPress is broken” situation; it is almost always one identifiable plugin file path until proven otherwise.

Common symptoms

  • Critical error message immediately after activating or updating a specific plugin
  • Recovery email names the plugin that was paused for your admin session
  • PHP error log or wp-content/debug.log shows a fatal path under wp-content/plugins/plugin-slug/
  • Site works when the plugin folder is renamed but fails the moment it is restored
  • Only certain admin screens crash (plugin settings, builder, checkout) while other pages load
  • Plugin appears active in the database but front-end fatals until folder rename or recovery deactivate

Most likely causes

  1. 01 Plugin version incompatible with current PHP or WordPress after an update or host PHP bump
  2. 02 Conflict with another active plugin or the theme loading the same classes or hooks twice
  3. 03 Corrupt or incomplete plugin files after failed update, timeout, or manual edit
  4. 04 Plugin bootstrap calling remote APIs, license checks, or migrations that fatal when they fail
  5. 05 Autoloaded option or custom table corruption tied to plugin activation routines
  6. 06 Must-use or network-activated copy of the plugin still loading after you “disabled” the regular copy

What changed before the problem started

  • Plugin activated for the first time or reactivated after a long pause
  • Plugin or bulk plugin update within the last few minutes or hours
  • PHP version change in hosting panel the same day
  • WordPress core update paired with an outdated plugin still active
  • Import of plugin settings or demo data from another environment

Troubleshooting steps

  1. 01

    Open the recovery-mode email and deactivate the named plugin

    Find the “Your Site is Experiencing a Technical Issue” email on the admin address. Click the recovery link, log into wp-admin, and deactivate the plugin WordPress flagged. Exit recovery mode and test the front end in a private window. Success signal: homepage loads with that plugin off.

  2. 02

    Match the fatal to a plugin slug in hosting or debug logs

    Search today’s PHP log for “Fatal error” or “Uncaught Error” and note the path under wp-content/plugins/. That folder name is your target. Enable WP_DEBUG_LOG only briefly if logs are empty—never leave debug display on production. Success signal: one plugin slug identified before you rename folders.

  3. 03

    Rename the plugin folder via FTP or file manager

    In wp-content/plugins/, rename plugin-slug to plugin-slug.disabled. WordPress stops loading it immediately. Reload / and /wp-login.php. Success signal: critical error clears without changing anything else.

  4. 04

    Check must-use plugins and drop-ins if the fatal persists

    Inspect wp-content/mu-plugins/ and drop-ins like object-cache.php. A fatal there mimics a regular plugin outage. Temporarily rename only the suspect mu-plugin after backup. Success signal: log path moves out of mu-plugins or drop-ins, or fatals stop after mu-plugin rename.

  5. 05

    Roll back or update the plugin to a compatible version

    Restore the previous plugin zip from backup or vendor archive, or install the hotfix release cited in the changelog. Read PHP and WordPress “Requires” lines before reactivating. Test checkout, forms, and cron-heavy features. Success signal: plugin active again with no new fatals after several requests.

  6. 06

    Document and stage future changes for that plugin

    Turn off auto-updates for the plugin until staging proves the next release. Record PHP version, conflicting plugins, and log lines for support tickets. Success signal: production stable; staging clone ready for the next update attempt.

When to stop troubleshooting

Stop if you cannot access files, logs implicate core WordPress rather than a plugin path, multiple plugins fatals interleave and you lack staging, database migration damage is suspected, or the site is live commerce during peak sales. Escalate with plugin slug, version, activation time, full log stack trace, and backup timestamp instead of enabling more plugins on production.

Information to collect before requesting help

  • 01 Plugin name, folder slug, and version (and whether it was just activated or updated)
  • 02 Whether recovery-mode email arrived and which plugin it named
  • 03 Full fatal error line from PHP or debug.log with file path
  • 04 PHP version, WordPress version, and active theme
  • 05 Other plugins updated or activated the same day
  • 06 Whether must-use plugins or object-cache drop-ins are present
  • 07 Backup availability from before the plugin change

How a professional repairs the problem

We trace the fatal to a single plugin path using recovery notices and server logs, then isolate it with deactivate or folder rename without dismantling your whole plugin stack. After access returns, we roll back or patch to a compatible build, flush caches, bisect conflicts on staging, and re-test critical flows (login, forms, checkout, cron). You get clear notes on whether the root cause was version skew, conflict, corrupt files, or migration—and a safer update path so the same plugin does not trigger another site-wide critical error.

Frequently asked questions

Does deactivating the plugin delete my data? +
Deactivation stops PHP from running; most plugin data remains in the database and uploads. Some features disappear until you reactivate a working version or migrate to another plugin.
Recovery mode fixed admin but visitors still see the error—why? +
Recovery mode pauses the plugin only for your logged-in recovery session. Other visitors still load the broken code until you fully deactivate the plugin or rename its folder.
Can I fix this by reinstalling WordPress core? +
Reinstalling core files does not fix a plugin fatal. Disable or replace the crashing plugin first; reinstall core only if logs show corrupt WordPress files unrelated to wp-content/plugins.
Two plugins seem to conflict—do I delete one? +
Disable one on staging, identify the pairwise conflict, then choose rollback, alternative plugin, or vendor patch—not permanent deletion on live without backups and a migration plan.
Is this the same as a white screen of death? +
Often the same root fatal. Newer WordPress shows the critical-error message instead of a blank page. Recovery steps—disable the plugin named in logs—apply to both presentations.
Should I increase PHP memory to fix the plugin fatal? +
Raise memory only when logs explicitly say “Allowed memory size exhausted.” Most plugin critical errors are code bugs or incompatibilities; masking them with higher limits can hide the real fix.

Repair dispatch

Still Need Help Fixing Your Website?

If you are not comfortable editing website files, changing server settings, repairing a database, or troubleshooting a live website, professional help may prevent additional damage or downtime. We will review the problem before accepting the repair.

  • You will receive a clear explanation of the likely cause.
  • We will tell you if the issue falls outside our repair scope.
  • No additional work will be performed without approval.
  • A backup should be created whenever access and website condition allow it.
Emergency repair Request diagnosis

Do not share passwords through an unencrypted contact form.

Written by Website Rescue

Last reviewed

Platform note: Full rescue available for WordPress and self-hosted sites. Wix, Squarespace, Webflow, Weebly, and similar closed builders have very limited backend access — fixes may not be possible. I will tell you honestly before we start.