Plugins and themes expand WordPress with features and design options. However, not all extensions work independently of each other. Two plugins can affect the same features, a theme can collide with a plugin, or an extension may no longer be compatible with the WordPress or PHP version being used.
The consequences range from minor display errors to a completely inaccessible WordPress admin area. Typical symptoms include JavaScript errors, forms that no longer work, faulty layouts, HTTP 500 errors, critical WordPress errors, or features that suddenly stop responding after an update.
Therefore, the most important rule in troubleshooting is: Do not guess, but systematically narrow down the components involved.
Briefly explained: A plugin or theme conflict can be most reliably identified by reproducing the error and then systematically ruling out individual components. Ideally, this should be done on a staging or test environment. Error logs and WordPress debugging can additionally show which component is actually involved in the error.
What is a plugin conflict in WordPress? #
A plugin conflict occurs when an extension does not work properly with another component of the WordPress installation.
This can happen, for example, between two plugins. Likewise, a plugin can conflict with the active theme, a specific WordPress version, the PHP version, or custom code.
None of the plugins involved necessarily have to be „bad“ or buggy. Two individually functioning extensions can interfere with each other because, for example, they use the same hooks, JavaScript libraries, data, or functions.
What is a theme conflict? #
A WordPress theme is not just made up of colors and layout either. Themes can contain PHP code, JavaScript, templates, custom functions, and sometimes extensive additional systems.
A conflict can therefore arise if a theme does not work correctly with a plugin or another component.
This is especially true for extensive themes that come with their own page builder features, custom post types, widgets, shortcodes, or additional extensions.
A child theme can also be the cause if custom or outdated code is used there.
How do you identify a potential plugin or theme conflict? #
A conflict does not always manifest through a clear error message. Sometimes, a specific function simply stops working.
Particularly suspicious is a problem that begins immediately after the installation, activation, or update of a plugin or theme.
Other typical symptoms include a suddenly broken layout, an unresponsive editor, missing features, JavaScript errors, an HTTP 500 error, or the WordPress notification about a critical error.
Even an unusually slow website can be caused by a problematic extension without WordPress displaying a visible error message.
The time of the error is an important clue #
Before you deactivate plugins or modify files, consider when the problem first occurred.
When a website works smoothly for months and fails immediately after a plugin update, that update is a much better starting point than randomly disabling some other extension.
The same applies after a theme update, a change in the PHP version, or a WordPress core update.
Practical Tip: Document for important websites which updates or changes were made immediately before an error occurred. This information can significantly shorten troubleshooting.
Conflict or isolated error? #
Not every plugin error is automatically a plugin conflict.
If a plugin already causes a PHP fatal error on its own, there may be a bug or an incompatibility in this plugin.
We tend to speak of a classic conflict when component A works on its own and component B also works on its own, but the problem arises as soon as both are active together.
This distinction is important because different solutions result from it.
Create a backup before troubleshooting #
Before making changes to plugins, themes, or configurations on a live website, you should have a recent backup.
This is especially true for WooCommerce stores, member areas, and other dynamic websites whose data is constantly changing.
A backup is not the actual diagnostic method. It serves as a safeguard in case a change has unexpected consequences.
Staging instead of debugging on the live website #
If the situation allows, a more comprehensive conflict diagnosis should not be carried out directly on the production website.
A staging or test copy makes it possible to deactivate plugins and themes, test PHP versions, and use debugging without visitors seeing every change immediately.
This is especially important if the website processes orders, bookings, forms, or other business-critical functions.
Important: A staging website is only meaningful as a diagnostic environment if it maps the problematic live environment with sufficient accuracy. Different plugin versions, PHP versions, or configurations can lead to different results.
Reproduce the error first #
Before looking for a cause, you should know how to reliably trigger the error.
Assuming a contact form is not working, the statement „The form sometimes doesn't work“ is hardly sufficient for a controlled diagnosis.
A concrete description is more helpful: the form can be filled out, but after clicking „Send“, a specific error message appears.
The more precisely the bug can be reproduced, the easier it is to determine after each change whether it still persists.
Test suspicious plugin first #
If the error started immediately after a change to a specific plugin, you should start with that plugin.
Temporarily disable it and then reproduce the exact same process.
If the problem disappears, that is a strong indication of the plugin's involvement. However, it does not yet prove that the plugin is the sole cause.
The error may only occur in combination with a second extension, the theme, or the PHP version being used.
What to do when no plugin is obviously suspicious? #
If no temporal relationship is discernible, controlled deactivation may become necessary.
In a test environment, the normal plugins can first be deactivated and then reactivated individually or in logical groups.
After each change, the previously defined error is tested again.
As soon as the problem occurs again, the circle of involved extensions can be narrowed down considerably.
Important: Do not delete plugins during conflict diagnosis. Disabling is usually sufficient. Depending on the plugin, deleting it may remove additional data or settings, which unnecessarily complicates the diagnosis.
Why „disabling all plugins“ alone is not yet a diagnosis #
Assuming you deactivate 25 plugins and the website works again afterwards, all you know is that at least one of these plugins could be involved in the problem.
Which extension is responsible has not yet been clarified by this.
The actual diagnosis takes place during controlled reactivation. During this process, you should check after every relevant change whether the original error can be reproduced again.
This is the only way to reliably isolate the cause.
Re-enabling plugins sensibly #
With a small WordPress installation, plugins can be reactivated individually and then tested.
When there are a very large number of extensions, group-by-group diagnosis can be faster. As soon as the error occurs again within a group, only that specific group is further subdivided.
Regardless of the method, it should always remain traceable which extensions were active during which test.
Observe plugin dependencies #
Some WordPress plugins are not completely independent. For example, add-ons may require a main plugin.
If the main plugin is deactivated, the add-on may also stop working. This is not a conflict, but an expected dependency.
Take such relationships into account during diagnosis so that an expected loss of function is not mistakenly interpreted as a new error.
Don't forget the must-use plugins #
In addition to regular plugins, WordPress can use so-called must-use plugins.
These are typically located under:
wp-content/mu-plugins/
They are loaded differently than regular plugins and appear separately in the WordPress admin area.
Even if you have deactivated all normal plugins and a problem still persists, you should therefore not automatically conclude that no plugin code at all can be involved.
Manually disable plugin when wp-admin is inaccessible #
If a plugin causes a critical error and you can no longer access the WordPress admin area, the plugin can be disabled manually with appropriate file access.
Normal plugins are located under:
wp-content/plugins/
If the affected plugin is known, its directory can be temporarily renamed.
From:
wp-content/plugins/beispiel-plugin/
could for example temporarily:
wp-content/plugins/sample-plugin-deactivated/
become.
WordPress can then no longer load the plugin normally under its expected path.
Exclude theme as cause #
If the plugin diagnosis does not yield a clear cause, the active theme should be checked as the next area.
On a suitable test environment, you can temporarily activate a current WordPress standard theme.
If the error disappears with the default theme, the previous theme or an interaction between the theme and plugin is a logical starting point.
If the error persists unchanged, the theme is less likely to be the cause – however, this does not completely rule out every interaction.
Differentiate between parent theme and child theme #
If the website uses a child theme, this should be considered separately in the diagnosis.
An error can occur, for example, in a customized:
functions.php
or be located in an overridden template of the child theme.
The parent theme itself can function completely correctly in the process.
If the error only started after a change to the child theme, this exact modification should therefore be examined first.
Theme change on a production website #
A theme change can affect navigation, widgets, templates, and the entire layout.
This is why a theme should not be changed lightly on a live website just to „take a look.“.
For a comprehensive theme diagnosis, a staging environment is usually the better choice.
Consider WordPress version #
Plugins and themes are developed and tested for specific WordPress versions.
If a problem occurs immediately after a WordPress core update, a previously unnoticed incompatibility may have become apparent.
This does not automatically mean that the WordPress update is faulty.
Instead, check whether the extensions involved are intended for the WordPress version being used and are actively maintained.
PHP version as a conflict factor #
PHP is the server-side programming language on which WordPress and a large part of its extensions are based.
Older plugin or theme code may use functions that have been changed or removed in a newer PHP version. Conversely, current software may require a PHP version that is not yet in use on the server.
Therefore, if an error occurs immediately after a PHP version change, the compatibility of the involved components should be checked.
We will cover the exact procedure under Change PHP version for WordPress and check compatibility.
Do not revert PHP version as a permanent solution #
If a website works with an older PHP version and fails with a newer version, temporarily switching back to the previously working version can help make the website accessible again.
However, this should not be considered an automatic permanent solution.
The actual question is which component is incompatible with the new environment and whether an update or replacement is available for it.
Practical Tip: „It works with old PHP“ is important diagnostic information, but not yet a sustainable solution to the problem.
Use error logs for conflicts #
When encountering visible PHP errors, you should not rely solely on deactivating plugins to find the cause.
An error log can already provide concrete clues.
An entry with a path like:
wp-content/plugins/sample-plugin/...
points to code within a plugin.
A path like:
wp-content/themes/beispiel-theme/...
leads in the opposite direction toward Theme.
Particularly helpful are the error type, file path, line number, and timestamp.
Use WordPress debugging effectively #
When the normal server logs do not provide enough information, WordPress debugging can provide additional clues.
Important constants are:
WP_DEBUG
WP_DEBUG_LOG
WP_DEBUG_DISPLAY
How to use these features in a controlled manner and evaluate error logs is covered under Enable WordPress debugging and use error logs.
Attention: Debugging on a production website should not result in detailed PHP errors being permanently displayed publicly. Logs can contain internal technical information.
PHP Fatal Error is particularly informative #
When a conflict leads to a fatal PHP error, the log often contains a specific error message.
Examples of relevant components are:
PHP Fatal error
Uncaught Error
Call to undefined function
Cannot redeclare
Class ... not found
Such messages can provide clues as to which components are colliding or which dependency is missing.
Detect JavaScript conflicts #
Not every WordPress conflict causes a PHP error.
For example, if a menu, popup, form, slider, or page builder stops responding, it may be due to a JavaScript issue.
What is typical here is that the page basically loads, but certain interactive functions no longer work.
The browser's developer tools can display JavaScript errors in such cases. The chronological connection to plugin or theme updates remains an important clue here as well.
CSS conflicts are not PHP conflicts #
If a function works technically but looks wrong, there may be a CSS conflict.
A plugin can, for example, load global CSS rules that affect theme elements.
The result can be a broken layout, an incorrect font size, or an invisible element, even though WordPress and PHP are working without errors.
In this case, a PHP error log usually does not help with the actual cause. The browser developer tools are better suited for CSS problems.
Cache can distort the diagnosis #
After disabling a plugin or changing the theme, a cached version of the website may still be served.
This can create the impression that a change had no effect.
Therefore, after a relevant change, you should consider whether browser, WordPress, server, or CDN caches might be involved.
Clearing the cache, however, is not a fix for a real plugin conflict. It merely ensures that you can reliably assess the current state.
Optimization plugins as a potential source of conflict #
Performance plugins can minify, defer loading of, combine, or otherwise modify CSS and JavaScript files.
If a website suddenly shows display or JavaScript problems after activating such an optimization, it should be checked which optimization function is triggering the error.
It is then often not necessary to permanently remove the entire performance system. A single optimization option or a targeted exception can be the actual cause.
Security plugins as a potential source of conflict #
Security plugins sometimes integrate deeply into WordPress. They can limit login attempts, check files, filter requests, or block certain actions.
If a function no longer works after a security configuration change, it should therefore also be checked whether a legitimate request is being blocked.
However, the solution should not be to permanently disable the entire security solution. The goal is to identify the specific rule or function.
Page builder and theme conflicts #
Page builders work closely with the theme, JavaScript, CSS, and WordPress.
If an editor no longer loads or certain widgets are malfunctioning, multiple layers may therefore be involved.
Here, the question of what was changed immediately before the problem occurred is also particularly helpful.
Changing the theme or deactivating all plugins on a live website should not be the first reflex.
Conflicts with multiple plugins #
Sometimes a problem is not caused by a single plugin, but only by a specific combination.
Plugin A works by itself. Plugin B also works by itself. If both are active, the error occurs.
That is precisely why controlled reactivation during conflict diagnosis is so important.
If it is merely determined that the website functions with deactivated plugins, such an interaction remains undetected.
A plugin is consuming an unusually high amount of resources #
Not every conflict results in a visible error message. For example, a plugin can generate very slow database queries or require an unusual amount of PHP memory or CPU time.
The website might then simply appear slow or unstable.
If performance is the main symptom, one should therefore not only look for classic PHP errors.
We cover the detailed performance diagnosis under WordPress is slow: Finding causes and improving loading time.
Properly classifying memory errors #
A resource-intensive plugin can cause PHP to reach its available memory limit.
For example, the error log may then contain:
Allowed memory size ... exhausted
appear.
Simply increasing the limit may initially eliminate the symptom without resolving the root cause.
If a single plugin requires an unusual amount of memory, it should therefore be investigated why this consumption occurs.
We explain more about this under PHP Memory Limit in WordPress: Identify and fix errors.
Check plugin compatibility details #
If a specific plugin has been identified as the cause, you should check its current requirements and documentation.
Particularly relevant are the supported WordPress and PHP versions as well as known dependencies.
Looking at the changelog of a current version can also be helpful if the error occurred after an update.
Update plugin or reset? #
If an error occurs immediately after a plugin update, a corrected newer version may already be available.
A temporary rollback to a previous working version can be useful in certain situations for recovery. However, security aspects must be taken into account.
An outdated version should not be used permanently if it contains known security vulnerabilities.
The long-term solution is a compatible and maintained version or, if necessary, a suitable alternative.
Automatic updates and conflicts #
Automatic updates are fundamentally helpful in keeping WordPress components up to date. For complex, mission-critical websites, however, it can still make sense to deliberately plan the update strategy.
Crucial factors in this regard are current backups, a reliable recovery capability, and, where appropriate in the case of major changes, testing in a staging environment.
The alternative cannot be to leave plugins unpatched permanently out of fear of conflicts.
Outdated plugins are not a good permanent solution #
If a plugin has not been maintained for a long time, the likelihood of future compatibility and security issues may increase.
Leaving a plugin on an old version just because the website currently works with it often merely postpones the problem into the future.
For extensions that are permanently no longer maintained, it should therefore be checked whether an actively maintained alternative is available.
What to do when the conflict has been clearly identified? #
Once you have identified the component involved, there is no single universal solution.
Depending on the cause, updating the plugin or theme may be sufficient. In other cases, a specific setting must be changed, an incompatible extension must be replaced, or custom code must be corrected.
In the event of a conflict between two plugins, you should check whether the developers offer a known solution or compatibility setting.
The important thing is not simply to maintain the test state. For example, if you deactivated an important security or shop plugin for the diagnosis, the website subsequently requires a working final configuration.
Report error to the plugin or theme developer #
When a reproducible conflict can be clearly narrowed down to specific components, precise technical information is much more helpful to the developer than the statement „The plugin doesn't work.“.
Helpful are the used WordPress, PHP, plugin, and theme versions, the specific error message, a relevant log entry, and a reproducible description of how the error can be reproduced.
In the event of a conflict between two extensions, both participating components should be named.
Test completely after repair #
When the original error has disappeared, you shouldn't just check the home page.
Test in particular the function that was originally affected. In the case of a business website, forms, login, navigation, search, and other important functions may additionally be relevant.
For a WooCommerce store, the shopping cart and checkout should also be checked after a major technical change.
Only when the relevant functions are working correctly again is the conflict resolution complete.
Revert temporary diagnosis changes #
During troubleshooting, plugins may be disabled, themes switched, debugging enabled, or caches modified.
After completing the diagnosis, you should check which of these changes were intended only for the test.
In particular, publicly visible debug outputs should be disabled again on a production website.
What you had better not do in the event of a suspected conflict #
Above all, avoid frantic multiple changes. If you simultaneously delete plugins, change the theme, modify PHP, and edit configuration files, a clean diagnosis becomes nearly impossible.
Also, do not delete extensions just to rule them out for testing purposes. Disabling them is usually sufficient and preserves the initial state much better.
Even a complete WordPress restore should not automatically be the first step if a single conflict can be diagnosed specifically.
Basic rule: Reproduce the bug, change one variable, test again, and document the result. This approach is slower than random trial and error – but it leads to the actual cause much more reliably.
What information helps CURIAWEB support? #
If you suspect a plugin or theme conflict on a WordPress website at CURIAWEB, describe as precisely as possible which function is no longer working and since when the problem has existed.
Particularly helpful are the affected URL, the specific error message, the approximate time it first occurred, and information about which plugin, theme, WordPress, or PHP version was updated or changed immediately beforehand.
If an error log already exists, send the relevant excerpt with timestamp. A complete log with thousands of older entries is usually less helpful for a targeted diagnosis.
Do not send passwords unsolicited.
Summary #
Plugin and theme conflicts in WordPress can manifest in very different ways. Not only critical PHP errors, but also display issues, JavaScript errors, slow loading times, or individual functions that no longer work can indicate a problematic interaction.
The most important starting point is the chronological context: What was installed, updated, or changed immediately before the error occurred?
A professional conflict diagnosis should preferably take place on a staging environment. The error is first reproduced and then suspected components are systematically ruled out. Plugins are not deleted indiscriminately, but rather deactivated and selectively reactivated. The theme, child theme, WordPress version, and PHP version must also be taken into account if necessary.
Error logs and WordPress debugging can significantly speed up diagnosis because they provide specific clues about the files and errors involved. Once the cause has been found, not only should the visible symptom be eliminated, but a permanently compatible and secure configuration should be established.
