A wishlist or compare plugin sits close to the product page, sharing space with the theme, the page builder, and often another plugin doing something similar. When one breaks — buttons that do nothing, items that don’t save, a comparison table that never loads — it’s rarely the plugin’s own code at fault. It’s two things reaching for the same hook, the same JavaScript event, or the same button markup in different ways.
Before you buy, one quick test
Reversible, five minutes. Deactivate every other plugin except WooCommerce and the wishlist or compare plugin itself, then test the button.
If it works, one of the deactivated plugins is the conflict, and re-enabling them one at a time shows you which. If it still fails with everything else off, the conflict is with the theme rather than another plugin, which points us somewhere different from the start. Either way, reactivate everything when you’re done testing so nothing else is left disabled.
Note down anything unusual you see during this test — a console error, a delay before it fails, whether it works the first time and not the second. Small details like these often point straight at the mechanism rather than just confirming there’s a problem.
Wishlist / compare plugin conflict
Wishlist or compare buttons aren't working — items don't save, or the comparison table won't load. We find which plugin or setting is conflicting and fix it.
- Full backup taken before we start
- If we can’t fix it, you get your money back
- We never ask for your own password
This or something else?
| Wishlist or compare button does nothing | This fix covers it |
| Items added but not saved between visits | This fix covers it |
| Comparison table not loading or showing blank | This fix covers it |
| General plugin conflict unrelated to wishlist or compare | Plugin conflict diagnosis & resolution |
| Variation selector broken, not wishlist | Product variation display errors |
What you are seeing
- Wishlist or “add to compare” buttons that do nothing when clicked, with no error visible to the customer
- Items added to a wishlist that vanish on the next visit, as if they were never saved
- A compare table that never loads, or loads with no products in it
- The conflict may only appear on some products, some devices, or for logged-out visitors
- It may have started after a theme or plugin update with no obvious connection to this plugin
Common causes
- Two plugins registering the same AJAX action or JavaScript hook, so only one ever actually runs
- A caching plugin serving a stale page that doesn’t reflect the visitor’s current wishlist state
- The theme or builder overriding markup the plugin depends on to find its own button
- Wishlist data stored in a session or cookie that something else on the site is clearing
- A JavaScript error earlier on the page stopping every script that loads after it from running at all
What we do
- Take a full backup before touching anything
- Reproduce the failure and check the browser console for JavaScript errors at the point it happens
- Isolate the conflict by testing with other plugins deactivated one at a time, in a controlled order
- Check whether caching is serving a version of the page without the correct wishlist state
- Resolve the conflict — reordering script loading, excluding the affected page from cache, or a targeted code fix
- Re-test wishlist and compare functionality across the affected products and devices
What is included
- Wishlist and compare functionality working, verified on the affected products
- The specific conflicting plugin or setting identified and named, not just patched around
- Caching configuration checked and adjusted if it played a part
- The pre-fix backup, kept for 30 days
Not included
- Replacing the wishlist plugin with a different one, which is a bigger decision than this fix
- Building wishlist features the plugin doesn’t natively support
- Conflicts introduced by future plugin updates, which would need their own visit
- Design changes to how the wishlist or compare page looks
Questions about this fix
Do I need to know which plugin is causing it before I buy?
No — finding it is the job. Naming what you've already tried, if anything, saves time, but you don't need a diagnosis of your own.
Could deactivating plugins during testing affect my live store?
We do this on a backup or staging copy where possible, or during low-traffic hours if it has to be live. Deactivating a plugin briefly doesn't delete its data, so nothing is lost either way.
The wishlist works for me but not for customers. Why?
Usually caching — you're likely logged in, which often bypasses the cache, while a logged-out visitor gets a cached page that doesn't reflect their wishlist state. It's one of the first things we check.
Will this happen again after the next plugin update?
It can, if the same two plugins keep colliding on the same hook. If that's the pattern, we say so and flag it as a recurring conflict worth resolving differently rather than patching each time.
Can you just remove one of the conflicting plugins?
Only with your agreement — one of them may be doing something you rely on. We tell you what each one contributes and let you decide, rather than removing functionality you didn't ask us to.
Related fixes
If this is the second time this year
A bad update breaking the site is a symptom of updates not being tested first. Care plans run every update on a staging clone before it reaches your live site, which is the actual fix for this happening again.
Your access, your rules
Create a separate admin account for us and delete it when we are done. For anything else, we get in touch and agree a method — never a form field on this site, never by reply to an email.
We back up first, always
Before anything is touched we take a full backup and keep it for 30 days. If a fix goes wrong, we put the site back exactly as it was.
If it is not what you bought
If the problem turns out smaller than what you ordered, we refund the difference. If it is bigger, we stop and send a quote before doing any extra work.
If we cannot fix it
You get back what we received. Diagnosis is on us — you only pay when the problem is actually solved. The payment processor takes its fee before the money reaches us, so we never hold it and it is not ours to return. That is true here as everywhere else.
If it comes back
Reply within seven days of delivery and we put it back on the bench at no cost. The fix is not finished until it holds.
What we are responsible for
If something goes wrong with a fix, our responsibility is limited to what you paid for it. We take a full backup first so mistakes can be undone, and we tell you before doing anything outside what you bought.