A plugin fatal can block both public pages and wp-admin. WordPress can be told the plugin is unavailable through WP-CLI or by renaming its directory; direct serialized database editing should be the last resort.
Preserve evidence and the plugin files. Deactivation is containment, not the final diagnosis.
Identify the plugin from evidence
Read PHP/hosting logs for the fatal path and timestamp. Confirm plugin directory, main file, version and the action that triggered failure.
/wp-content/plugins/example-plugin/...Do not disable a plugin solely because its name appears later in the stack. The first failing call and recent change are stronger evidence.
Back up before intervention
Take database/files backup or hosting snapshot. Confirm cPanel, Plesk, SFTP or SSH reaches the active document root.
Do not run the plugin’s uninstall/delete action; it may remove settings/tables. A safe deactivation leaves data available for repair.
Check whether the plugin controls maintenance, authentication or essential integrations and plan the temporary impact.
Use WP-CLI when WordPress can bootstrap
From the correct document root:
wp plugin deactivate example-plugin
wp plugin status example-pluginRun as the site’s hosting user and check exit output. If PHP fatals before WP-CLI loads, use --skip-plugins=example-plugin where supported or the filesystem method.
For multisite, inspect network activation and use network-aware commands.
Rename the plugin directory
Through file manager/SFTP/SSH, rename only the identified directory:
example-plugin -> example-plugin.disabledWordPress will not find the active path and should deactivate it when loading the plugins list. Preserve ownership and do not move the directory into a publicly downloadable archive.
Clear OPcache if the fatal persists despite the file path change.
Handle must-use and drop-in components
Must-use plugins in wp-content/mu-plugins load automatically and do not use normal activation. Drop-ins such as object-cache.php, db.php and advanced-cache.php also load separately.
Follow the hosting/plugin’s documented disable process; renaming a companion normal plugin may leave its drop-in active.
Back up and verify cache/database behaviour before moving a drop-in.
Avoid raw database editing
active_plugins is a serialized option. Manual text editing can corrupt the value and deactivate unrelated plugins.
If filesystem and WP-CLI are unavailable, use a WordPress-aware administration tool or PHP code that safely unserializes/updates through WordPress after backup.
Multisite network-active plugins live in a different option and require separate handling.
Diagnose before reactivation
Keep the original directory/package and capture the fatal. Compare compatibility, dependencies, PHP version and file completeness in staging.
Update/roll back from a trusted source, or correct site-owned integration code. Take a fresh database backup before any plugin schema migration.
Do not reactivate repeatedly on production to reproduce the same outage.
Assess dependency impact before disabling
Search active theme and plugin code/logs for classes, blocks or shortcodes supplied by the component. A dependent add-on can fatal after its base plugin is disabled.
Contain the dependency set in the vendor-documented order. If the plugin controls login, caching, multilingual routing or integrations, prepare an alternative and tell stakeholders what is temporarily unavailable.
Preserve security boundaries
Do not disable access-control or security code without checking which protection moves to the host/firewall. Maintenance mode must not expose private content previously restricted by the plugin.
Review anonymous access in a clean browser. Emergency containment authorises the smallest repair, not a permanent reduction in security.
Verify containment and recovery
Test public pages, login, administrator and functions the plugin previously supplied. Inform stakeholders about temporarily missing features.
After the repaired version passes staging, restore the canonical directory, activate once and inspect logs. Recurring care should retain emergency access and plugin inventory so a single fatal can be contained without damaging the rest of WordPress.