How to fix WooCommerce brand filters broken by plugin cookies

When a WooCommerce product filter works for some visitors but fails for others, the problem may not be the filter plugin itself. In one troubleshooting case, a brand filter behaved inconsistently across different PCs and browser sessions because another plugin was setting a cookie that changed how product queries were handled.

The root cause was the Multi-Location Inventory plugin. After a visitor selected a store location on a product page, the plugin stored a cookie that overrode the brand filter query instead of allowing both pieces of functionality to work together. The fix required reproducing the bug with the same cookie state, patching the query logic, and deploying a script that cleared the conflicting cookie automatically for visitors.

Issue background

A WooCommerce site had a “Filter by brand” feature that worked correctly for some users but failed on other computers, particularly in Google Chrome.

When the issue occurred, selecting a brand did not display the expected products. The full list of brands remained visible, multiple brands could still be selected, and neither single-select nor multi-select filtering produced the correct results.

The inconsistency made the issue difficult to diagnose. The same filter could work on one browser and fail on another, and at one point a computer where the feature had previously worked began showing the same problem.

Diagnosis

The most important step was reproducing the problem in the same browser state as an affected user.

A temporary browser bug-reporting tool was installed so an affected user could reproduce the issue while diagnostic information was collected. The report revealed a key difference between the failing browser and the developer’s browser: the affected browser had a cookie that the developer’s session did not.

That cookie was being created by the Multi-Location Inventory plugin whenever a user selected a store location on a product page.

Once the same cookie was manually added to the developer’s browser, the brand filter immediately broke there as well. This gave the team a reliable reproduction path and confirmed the root cause.

The issue was not simply that a cookie existed. The underlying conflict was that the Multi-Location Inventory cookie was overriding the brand filter query instead of working alongside it. As a result, the product query no longer respected the selected brand.

Resolution steps

The documented fix followed a useful troubleshooting pattern for client-side WooCommerce issues that affect only certain visitors:

  1. Reproduce the issue in an affected browser. If a bug only affects certain users, browser state matters. Ask an affected user to reproduce the problem rather than relying only on a clean developer session.
  2. Collect browser-specific diagnostics. A temporary bug-reporting tool was used to capture the state of the affected browser. This revealed the cookie difference that normal testing had missed.
  3. Compare working and failing sessions. The developer identified the Multi-Location Inventory cookie as the only meaningful difference between the working and failing browsers.
  4. Recreate the cookie state locally. Adding the same cookie to the developer’s browser caused the brand filter to fail, confirming that the cookie was directly involved.
  5. Patch the filter logic. The query handling was updated so the store-location cookie and the brand filter could coexist rather than one overriding the other.
  6. Clear the stale cookie automatically. A script was deployed to clear the conflicting cookie for every visitor on their next page load. This meant users did not need to perform a hard refresh manually.
  7. Retest the filter repeatedly. After the patch, the developer reproduced the previous failure path several times and confirmed that the fix worked consistently.
  8. Treat the patch as temporary if the underlying plugin is still flawed. The documented fix addressed the immediate site conflict, but the developer noted that the bug ideally should also be reported to the Multi-Location Inventory plugin’s developers.
  9. Test future plugin updates on staging. Because a future plugin update could change the affected code path, updates to the Multi-Location Inventory plugin should be tested in staging before production deployment.

The investigation also reinforced a practical debugging lesson: when an issue is impossible to reproduce in a clean developer environment, gathering data directly from an affected user’s browser can reveal cookies, storage values, cached assets, or other state that is otherwise invisible.

Final outcome

The brand filter was restored after the query conflict was patched and the stale Multi-Location Inventory cookie was cleared automatically for visitors. Users no longer needed to perform a hard refresh to receive the fix.

The root cause was considered highly likely to have been the underlying issue all along, even though earlier troubleshooting had uncovered other real performance and functionality concerns. Once the bug could be reproduced consistently, the cookie conflict became clear.

If a WooCommerce filter works for some users but not others, inspect more than the filter plugin. Cookies created by inventory, geolocation, personalization, or session plugins can alter product queries in ways that only affect certain browser states.

If you are dealing with WooCommerce filters, plugin conflicts, browser-specific bugs, or cookies that change product-query behavior, contact Freshy. Our WordPress team can help reproduce client-side issues, diagnose plugin conflicts, and implement stable fixes.