If your WordPress site broke right after installing, updating, or activating a plugin, you're almost certainly looking at a plugin conflict. The fastest fix: deactivate all plugins, confirm the site recovers, then re-enable them one at a time until the broken one shows itself. That isolates the cause in minutes instead of guessing.
Plugin conflicts show up a few different ways: a white screen, a fatal error banner, a broken layout, or a feature that stops working (checkout, forms, a slider). The fix process is the same regardless of symptom.
Isolate the plugin: disable all, then re-enable one at a time
This is the single most reliable diagnostic step, and it works whether or not you can log into wp-admin.
- Via FTP or the portal's file manager, go to
/wp-content/plugins/. - Rename the whole folder:
pluginstoplugins.bak. WordPress treats every plugin as deactivated without deleting anything. - Reload the site. If it works now, one of your plugins caused the problem.
- Rename the folder back to
plugins. - In
wp-admin → Plugins, activate plugins one at a time, reloading the site after each one. - When the site breaks again, the plugin you just activated is the conflict.
If you have shell access, wp-cli is faster than clicking through wp-admin:
cd /home/your-user/public_html wp plugin deactivate --all wp plugin activate plugin-slug-name
Run the second command once per plugin, checking the site between each. This is the same core technique used for tracking down the white screen of death, since a blank white page is one of the most common conflict symptoms.
Three most likely causes on our stack
1. PHP version mismatch
Older plugins sometimes call PHP functions that newer PHP versions removed, or they weren't tested against the version you're running. If the conflict started right after a PHP upgrade (or you're running a plugin that hasn't been updated in a while), roll back and test:
- In the portal, go to Services → your hosting → the PHP Version tile.
- Switch the domain to an older PHP version (7.4 through 8.3 are available).
- Reload the site.
If the older version fixes it, the plugin needs a compatibility update, or you need a replacement plugin. Don't leave the site on an old PHP version long-term as a permanent fix; older PHP loses security patches over time.
2. Two plugins fighting over the same thing
The classic case: two SEO plugins, two caching plugins, two security plugins, or two page builders active at once. They often register the same hooks, write to the same database options, or both try to control the same output (like the page <head>), and one wins in a way that breaks the other. The disable-and-re-enable process above catches this too, since the site usually breaks again as soon as both are active together, not necessarily from either one alone. If you suspect this, activate suspect plugins in pairs during your isolation pass rather than strictly one at a time.
3. A plugin writing bad data into the database
Rarer, but it happens: a buggy plugin corrupts an option row or a custom table on activation, and the damage persists even after you deactivate it. If deactivating the plugin doesn't fully restore the site, check wp-admin → Tools → Site Health for flagged issues, and consider restoring from a recent backup taken before the plugin was installed rather than chasing the bad data by hand. The portal's Backups tile keeps daily backups you can restore from.
Turn on debug output to see the actual error
If the disable-all step doesn't immediately explain things, or you want to confirm which specific function or file is throwing the error, turn on WordPress debug logging in wp-config.php:
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
Reload the page, then check /wp-content/debug.log. The most recent entries will name the plugin file and function where the error occurred, which tells you exactly what to disable or downgrade. Full walkthrough of this process, including theme-side causes, is in fixing the WordPress white screen of death.
After you've found the culprit
- Update it. If a newer version exists, that's usually the fix. See updating WordPress safely for a backup-first update pattern.
- Check for a replacement. If the plugin is abandoned (no updates in a year or more), it's worth switching to an actively maintained alternative rather than fighting it again after your next PHP or WordPress core update.
- Report it if you can't fix it yourself. Most plugin authors have a support forum on WordPress.org; a clear description of the conflict (which other plugin, which PHP version) helps them fix it for everyone.
When to open a ticket
Open a ticket if you've isolated the conflict but can't safely deactivate the plugin yourself (for example, it's tied to a live store and you're worried about downtime), if the site won't come back even after deactivating all plugins, or if you suspect the database corruption case above and want a second opinion before restoring a backup. Support tickets go through the portal (Support → New ticket) and are handled by real people, not a bot queue. If credentials need to change hands as part of the fix, use the ticket's secure-share panel rather than pasting them into the ticket body.