How to Diagnose and Fix Plugin and Theme Conflicts in WordPress

Overview

Plugin and theme conflicts happen when two or more pieces of code in your WordPress installation try to do incompatible things — loading conflicting JavaScript libraries, overriding the same WordPress hooks, or fighting over database table structures. The result is usually a broken site, a white screen, or a feature that quietly stops working.

Most users hit this after an update. WordPress core updates change internal APIs, and plugins that haven’t kept up can start throwing fatal errors. Theme updates do the same thing, especially if you’re using a child theme that inherits from a parent that just changed its template structure.

This article covers how to isolate the conflicting plugin or theme, resolve the issue safely, and avoid making things worse in the process. Whether you’re on shared hosting, a VPS, or our Managed WordPress Hosting, the diagnostic process is the same — though managed hosting customers can also open a support ticket and we’ll handle it directly.

Prerequisites

• Admin access to your WordPress dashboard, or FTP/SFTP access to your server if the dashboard is inaccessible
• A recent backup of your site — do not skip this. Conflicts can sometimes hide underlying database issues that surface during troubleshooting.
• Access to your hosting control panel (cPanel, Plesk, or SSH) for file-level changes
• WordPress 5.0 or later (WordPress Safe Mode via Health Check plugin requires WordPress 5.2+)
• FTP client such as FileZilla, or SFTP access via terminal, if your wp-admin is returning a white screen or 500 error

Step-by-Step Instructions

Step 1 — Take a Full Backup Before Touching Anything

This isn’t optional. If you’re on cPanel, use the Backup Wizard under cPanel > Files > Backup Wizard to download a full account backup. If you have SSH access:

cd /home/yourusername
tar -czf backup-$(date +%Y%m%d).tar.gz public_html
mysqldump -u dbuser -p dbname > backup-$(date +%Y%m%d).sql

Replace yourusername, dbuser, and dbname with your actual values. Store the backup somewhere off-server before proceeding.

Step 2 — Check the PHP Error Log First

Before blindly deactivating plugins, check the error log. It usually tells you exactly which file is throwing the fatal error. In cPanel, go to Metrics > Errors. Via SSH:

tail -n 50 /home/yourusername/public_html/wp-content/debug.log

If debug.log doesn’t exist or is empty, enable WordPress debug mode by editing wp-config.php:

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

Set WP_DEBUG_DISPLAY to false so errors log to file rather than display publicly. Reproduce the issue, then check the log again. You’ll often see a line like Fatal error: Cannot redeclare function_name() in /wp-content/plugins/some-plugin/file.php on line 42 — that’s your culprit right there.

Step 3 — Use WordPress Safe Mode (Health Check Plugin)

If your dashboard is still accessible, install the Health Check & Troubleshooting plugin (it’s in the official WordPress repository). Once installed, go to Tools > Site Health > Troubleshooting and click Enable Troubleshooting Mode.

This disables all plugins and switches to the default theme — but only for your logged-in session. Visitors see the normal site. This is the cleanest way to test without affecting live traffic.

With troubleshooting mode active, re-enable plugins one at a time. After each one, test the problem behaviour. When the issue comes back, you’ve found the conflict. Then re-enable the remaining plugins to see if there’s a second plugin making it worse.

Step 4 — Deactivate Plugins via FTP if wp-admin Is Inaccessible

A white screen or 500 error usually means a fatal PHP error is preventing WordPress from loading at all. You can’t log in, so you need to deactivate plugins at the file level.

Connect via FTP/SFTP and navigate to /public_html/wp-content/. Rename the entire plugins folder:

mv /home/yourusername/public_html/wp-content/plugins /home/yourusername/public_html/wp-content/plugins_disabled

Reload your site. If it comes back, WordPress is working — the problem is a plugin. Now rename the folder back and deactivate plugins individually by renaming their subfolder inside /wp-content/plugins/. For example, to disable WooCommerce:

mv /home/yourusername/public_html/wp-content/plugins/woocommerce /home/yourusername/public_html/wp-content/plugins/woocommerce_disabled

Re-enable each one (rename back) and test until the error returns.

📝 Note: WordPress won’t show these as “deactivated” in the dashboard — it just can’t find them. When you rename them back, WordPress will show a notice that the plugin was deactivated due to a missing file. You may need to reactivate it manually from the Plugins screen.

Step 5 — Test the Default Theme

If deactivating all plugins didn’t fix the problem, the theme might be the issue. Switch to a default WordPress theme (Twenty Twenty-Four is the current one) via Appearance > Themes. If you can’t access the dashboard, rename your active theme folder via FTP or SSH:

mv /home/yourusername/public_html/wp-content/themes/your-theme /home/yourusername/public_html/wp-content/themes/your-theme_disabled

WordPress will fall back to the next available theme. If the site loads correctly with the default theme, your theme (or the interaction between your theme and a specific plugin) is the source of the conflict.

Step 6 — Identify the Specific Conflict Pair

Once you know which plugin or theme is involved, re-enable everything else and test with just the suspected plugin active alongside the theme. This confirms whether it’s a standalone plugin bug or an actual conflict between two specific components.

In my experience, the most common conflict pairs are: page builders (Elementor, Divi) with caching plugins, WooCommerce with payment gateway plugins after a WooCommerce major version bump, and SEO plugins with schema markup plugins both trying to output JSON-LD in the page <head>.

Step 7 — Resolve the Conflict

You have a few options once you’ve identified the conflict:

• Update the conflicting plugin or theme — check if a newer version addresses the compatibility issue. Always check the plugin’s changelog and support forum on wordpress.org before updating.
• Contact the plugin developer — open a support thread on the plugin’s WordPress.org page with your PHP error log output. Good developers respond quickly to conflict reports.
• Disable one of the two conflicting plugins — if both do overlapping things (two caching plugins, two SEO plugins), you probably only need one anyway.
• Use a code snippet to resolve the hook conflict — if you’re comfortable with PHP, you can unhook conflicting actions in a child theme’s functions.php or a site-specific plugin. Only do this if you understand the code involved.

⚠ Warning: Don’t edit plugin files directly. Any changes you make will be wiped the next time the plugin updates. Use a child theme or a custom plugin for code-level fixes.

Common Issues & Troubleshooting

White Screen of Death After Plugin Update

This is almost always a PHP fatal error. The plugin update introduced code that’s incompatible with your PHP version or another plugin. Check your error log first (Step 2). If your server is running PHP 7.4 and the updated plugin requires PHP 8.1+, that’s your answer — update PHP via cPanel’s MultiPHP Manager, or ask your host to upgrade it. On Host & Tech VPS plans you can switch PHP versions yourself via the control panel.

Site Loads But Specific Features Are Broken

This usually points to a JavaScript conflict rather than a PHP one. Open your browser’s developer console (F12 in Chrome or Firefox) and look at the Console tab for JavaScript errors. You’ll typically see something like Uncaught TypeError: $ is not a function, which means two plugins are loading conflicting versions of jQuery or one plugin is loading jQuery in no-conflict mode incorrectly. The fix is usually updating the offending plugin or changing the script loading order.

Conflict Only Appears on Specific Pages

Some plugins only load their scripts on specific post types or page templates. If the conflict only shows on WooCommerce product pages, for example, the conflict is almost certainly between WooCommerce and another plugin that hooks into the same template. Enable debug mode, reproduce the error on that specific page, and check the log for the file path — it’ll point directly to the plugin causing the issue.

Conflict Reappears After Fixing It

This happens when automatic updates are enabled and the conflicting plugin updates itself back to the broken version. Go to Dashboard > Updates and disable automatic updates for the specific plugin until a proper fix is released. You can also manage auto-update behaviour per plugin from the Plugins screen by clicking the “Enable auto-updates” toggle.

Fatal Error: Allowed Memory Size Exhausted

This isn’t always a conflict — but it can be triggered by one. A poorly coded plugin might have a memory leak that only surfaces when combined with other plugins. You’ll see this in the error log as Fatal error: Allowed memory size of NNNNNN bytes exhausted. As a temporary measure, increase the memory limit in wp-config.php:

define( 'WP_MEMORY_LIMIT', '256M' );

If memory usage keeps climbing, a specific plugin is leaking. Use the Query Monitor plugin to identify which plugin is consuming the most memory during a page load.

FAQ