A plugin conflict does not always mean one plugin is badly written. Two useful tools can compete for the same checkout field, rewrite rule, JavaScript event or database process. The visible symptom may appear far from the cause: a payment fails, a menu stops opening, product variations freeze or the whole site shows a critical error. The safe approach is always the same: back up, reproduce the problem, isolate one variable at a time, and test on staging before touching the live store.
1. Optimisation plugins versus builders and checkout scripts
Minification, JavaScript delay, unused-CSS removal and script combination can improve speed, but they can also change the order in which interactive code runs. A page builder, product filter, variation selector or payment form may depend on a script being available immediately. The symptom is often a feature that works after a refresh or only for logged-in users.
The fix: disable one optimisation feature at a time, beginning with JavaScript delay and aggressive CSS removal. Exclude checkout, cart and account scripts where the tool allows it, clear every cache layer, and test in a private window. Keep the settings that improve performance without changing behaviour; do not chase a score by breaking the buying journey.
2. Security or firewall rules versus payment callbacks
Payment gateways communicate with your site after the customer pays. A firewall, bot rule, country restriction or overly strict security plugin may block that callback because it arrives from an external server rather than a normal browser. The customer sees a successful payment while WooCommerce leaves the order pending, or the gateway reports a webhook failure.
The fix: check the payment provider's webhook or transaction log and the security plugin's blocked-request log for the same time. Allowlist only the gateway's documented endpoints or addresses, using the provider's current guidance, then run a small live or sandbox transaction as appropriate. Never solve this by turning the entire firewall off.
3. Translation and currency tools versus carts, emails and prices
Multilingual and multicurrency plugins may alter product URLs, sessions, cached pages, order emails and the way prices are displayed. A conflict can show the correct price on a product page but a different format in the cart, translate only part of checkout, or send an order email in the wrong language. Problems often appear only in one language or currency, which is why ordinary testing misses them.
The fix: test one complete order for every language and currency you actively sell in. Clear caches after changing strings or currency rules, check whether dynamic cart and checkout pages are excluded from page cache, and review compatibility settings between the translation tool, WooCommerce and the gateway. Keep a written matrix of what was tested so a later update can be checked the same way.
4. Backup, migration and maintenance tools versus scheduled jobs
Backup and migration plugins work with large files, archives, database tables and scheduled tasks. Another maintenance tool, object cache or security setting can interrupt the job, duplicate schedules or leave temporary files competing for limited server resources. The result may be a backup that appears to start but never completes, or a site that becomes slow at the same time each day.
The fix: inspect WordPress scheduled events and each tool's job log, remove duplicate backup systems, and schedule heavy work away from selling hours. Confirm that completed backups can actually be restored on staging. A backup is not proven because a plugin says it finished; it is proven when a restore works.
5. Duplicate galleries, sliders and schema tools loading the same libraries
Several plugins may each load their own copy of a slider, lightbox, icon library or structured-data output. Duplicates can cause jumpy product galleries, buttons that respond twice, conflicting search-engine metadata or JavaScript errors that stop unrelated features. This often happens when a theme already includes a feature and a plugin is installed to do the same job.
The fix: choose one owner for each feature. Disable the duplicate on staging, check the page source and browser console for repeated libraries or schema blocks, and test product galleries on mobile. Where a plugin offers a setting to disable its bundled library because the theme already supplies it, use that setting cautiously and retest every page type that depends on the feature.
Diagnose without creating a second problem
A calm isolation routine
Note the exact time and steps that reproduce the fault. Read the WordPress and WooCommerce logs, then use staging or a troubleshooting mode that does not affect visitors. Disable plugins in small groups, switch only one element back on at a time, and clear caches between tests. If the fault follows a theme change, test with a default theme on staging. Record the winning combination and update plugins one by one in future, with a backup before each batch.
Most conflicts are solvable once the pattern is identified. The mistake is changing ten settings during selling hours and having no route back.
Need this fixed? Email jay@jaylakum.com with your site URL, the symptom and when it started, and I will help you isolate the cause safely.
