How to fix WooCommerce brand filters and caching conflicts

A WooCommerce brand filter can appear unreliable when slow AJAX requests, stale browser data, and conflicting cache-control code overlap. In this case, adding a product-category exclusion triggered a critical WordPress error because two custom files declared the same cache-cancellation function. A separate investigation showed that filter requests silently fell back to full page reloads after five seconds, while Enterprise 2FA session handling prevented the WP Cloud page cache from operating. Removing the duplicate function, extending the filter timeout, forcing fresh filter responses, and correcting session handling restored reliable filtering and improved perceived site speed.

Issue background

A WooCommerce store had an intermittent filter by brand problem on product-category pages. The filter worked for some visitors but appeared stuck or ineffective for others.

Clearing the local browser cache temporarily restored the feature, but the problem returned later. That pattern suggested a cache-related issue, although the exact source was not immediately clear.

During troubleshooting, a product-category URL was added to a cache-exclusion list. The site then displayed a critical error and became unavailable.

The environment included several interacting systems:

• WooCommerce product-category filters
• WP Cloud page, object, and edge caching
• WP Rocket, although its page cache was not the active cache layer
• Enterprise 2FA for privileged WordPress users
• A custom cache-exclusion file
• A CSS & JS Refresher plugin installed during earlier troubleshooting

Diagnosis

The critical error and the unreliable filter had related caching symptoms but different immediate causes.

The site crash occurred because the same cache-cancellation function was declared in two PHP files. When the new exclusion activated both code paths, PHP attempted to load the duplicate function and stopped execution with a fatal error.

The brand filter itself was functioning, but the site responded slowly for some requests. The filter script allowed only five seconds for an AJAX response. When the server took longer, the script silently abandoned the AJAX update and reloaded the entire page. To visitors, that behavior looked like the filter had failed or reset.

Browser state made the issue appear inconsistent. The filter worked in an incognito window but failed in a normal browser containing older cached data.

The broader performance audit also found that Enterprise 2FA created session behavior that prevented WP Cloud page caching. Every request had to be generated dynamically instead of being served from cache, producing an initial server wait of roughly 3.5 seconds and increasing the chance that filter requests would exceed the five-second limit.

Resolution steps

1. Restore the site after the critical error. Temporarily disable the conflicting cache-cancellation file so WordPress can load again.
2. Inspect the PHP fatal error. Review the error log for a message showing that a function was already declared.
3. Find every function definition. Search custom plugins, must-use plugins, and cache-management files for the duplicated function name.
4. Remove the duplicate declaration safely. Consolidate the behavior into one maintained location or guard the function with function_exists() when appropriate.
5. Map the active cache layers. Confirm whether page caching is controlled by WP Cloud, WP Rocket, another plugin, or a combination of systems.
6. Remove unnecessary category exclusions. Do not exclude all product-category pages when the filter can be made compatible with caching.
7. Reproduce the filter delay while logged in and logged out. Measure the AJAX request rather than judging only the visible page behavior.
8. Review the filter fallback logic. Identify the timeout that causes the script to abandon AJAX and perform a full page reload.
9. Increase the request timeout. Allow enough time for slower connections or uncached server responses before triggering fallback behavior.
10. Add server-side cache busting. Ensure each filter interaction requests fresh results instead of reusing a stale browser response.
11. Correct 2FA session handling. Preserve Enterprise 2FA for administrator accounts while preventing its sessions from disabling public page caching for every visitor.
12. Verify WP Cloud caching. Confirm that public pages receive a nonzero cache age after the initial request and that later requests are served from cache.
13. Test normal and private browser sessions. A feature that works only in incognito usually indicates stale local data, cookies, or service-worker behavior.
14. Perform a one-time hard refresh. Clear pre-fix assets with Ctrl + Shift + R on Windows or Command + Shift + R on macOS.
15. Test with previously affected users. Validate the filter on devices and accounts that consistently reproduced the problem.
16. Remove obsolete troubleshooting plugins. Once server-side cache busting is in place, uninstall temporary tools such as CSS & JS Refresher when they are no longer needed.
17. Monitor perceived speed. Test real page navigation and filter responsiveness rather than relying only on automated performance scores.

A simplified defensive pattern for avoiding a duplicate custom function is:

if ( ! function_exists( 'custom_cancel_page_cache' ) ) {
    function custom_cancel_page_cache() {
        // Cache-control logic.
    }
}

This guard can prevent a fatal redeclaration, but it is not a substitute for consolidating duplicate custom code. The long-term goal should be one authoritative implementation.

Final outcome

The duplicate cache function was corrected, and the product-category exclusion that triggered the incident was removed because it was no longer necessary.

The brand filter timeout was increased, and server-side cache busting forced browsers to retrieve fresh filtered results. Enterprise 2FA remained active, but its session behavior was adjusted so WP Cloud page caching could operate normally.

Testing confirmed that the brand filter worked on previously affected workstations and user accounts. The site also felt more responsive because public pages no longer had to be rebuilt from scratch for every request.

The temporary CSS & JS Refresher plugin was removed after the permanent fix was verified.

The key lesson is that an intermittent WooCommerce filter issue may be a timing and caching problem rather than a broken filter query. Reliable diagnosis requires tracing the AJAX request, browser cache, PHP errors, user sessions, and active server cache as one system.

For help troubleshooting WooCommerce filters, WP Cloud caching, Enterprise 2FA conflicts, or WordPress critical errors, contact Freshy.