> ## Documentation Index > Fetch the complete documentation index at: https://vr-it-services-pro.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Plugin conflicts > The bisect procedure for finding and confirming a plugin conflict. # Plugin conflicts A plugin conflict is far more likely than a theme regression. This page is the procedure for finding and confirming one. **In reality** WordPress themes are rarely the cause of a new problem. The overwhelmingly common cause is a plugin that updated, a plugin you just installed, or a plugin whose cached assets are stale. ## The bisect procedure This works on every problem and takes five minutes. **1. Back up first** Files and database. This is what makes the next steps safe. **2. Deactivate every plugin** **Plugins → Installed Plugins → Deactivate** using the bulk action at the top. **3. Check the site** If the problem is gone, a plugin is the cause and you have narrowed it to that set. **4. Reactivate the first half** Check again. **5. Reactivate the second half** Check again. **6. Repeat within the failing half** Until you have isolated one plugin. **7. Confirm the culprit** Deactivate just that plugin and verify the problem returns when it is active. This final confirmation matters — it rules out coincidence. > [!WARNING] > > **Deactivating plugins can break the site in new ways.** A page builder, a forms plugin, or a security plugin may be required for other things to work. Have your backup ready, and do this on staging if you have it. ## Faster methods ### Via WP-CLI Much faster than clicking when you have shell access. ```bash theme={null} # Deactivate everything wp plugin deactivate --all # List what's currently inactive wp plugin list --status=inactive # Reactivate one wp plugin activate elementor ``` ### Via the database If the dashboard is unreachable, deactivate by editing the `active_plugins` option. ```sql theme={null} UPDATE wp_options SET option_value = 'a:0:{}' WHERE option_name = 'active_plugins'; ``` > [!WARNING] > > **Back up the database before running that query.** It deactivates every plugin, including your security plugins. Do it only when you have no other way in, and do not do it on a production site without a tested restore path. ## Confirming it is really a conflict > **The problem appeared right after a plugin update** > > Strong signal. Check each plugin's update timestamp against when the problem started. > **The problem followed a plugin install** > > Strong signal, though some plugins conflict with each other rather than with the theme. > **The problem follows your theme switch** > > Also plausible — a plugin may have been built for your previous theme's architecture. > **The problem appears only with caching** > > A "conflict" that only exists when a stale cached file is served. Clear all caches first. ## Where conflicts show up | Symptom | Usual cause | | - | - | | **Mobile menu will not open** | JavaScript error from a builder, slider, chat widget, or cookie banner | | **Header missing on some pages** | A page builder or header plugin that removes the theme header | | **Layout broken after a plugin install** | CSS specificity conflict, usually aggressive | | **Colors overridden** | A plugin injecting its own global styles | | **Content width wrong** | A plugin setting a container width, or a builder's full-width mode | | **Dark mode not applying** | A cache serving stale CSS, or a plugin forcing a colour scheme | | **Customizer will not save** | A security plugin blocking the request | | **Everything looks unstyled** | A CSS optimiser double-processing the theme's stylesheet | ## The CSS optimiser problem This one is specific to this theme and worth understanding. > [!WARNING] > > **The theme's main stylesheet is already served without blocking render** — it uses a `media="print" onload="this.media='all'"` swap with a `