Quote from Alex Dovlatov on April 21, 2026, 12:07

Hello

Thank you for the report. I checked your site and sorting appears to be working on my end — for example, sorting by price works correctly: https://drive.google.com/file/d/1uwMDcUQtlnA_3Ylp__lKG84rkEMQDjRa/view?usp=sharing

Regarding the core issue: HUSKY does not control what Oxygen Builder renders. If you are referring to the Load More button behavior, BeRocket Load More fires its own independent AJAX request and HUSKY simply does not intercept it — they work in parallel without awareness of each other.

There is a possible workaround for making page builder layouts compatible with HUSKY filtering — you can find the code snippet here: https://products-filter.com/make-page-builders-and-custom-template-filterable/

Please note this is not a guaranteed fix, but it may help in your case.

Could you please clarify exactly what is not working for you, or record a short video showing the issue? This will help us understand the specific problem and assist you better.

Quote from dillonlara115 on April 21, 2026, 14:01

Hello,
I've added error logs, many of which are related to husky and will send a video later today.

We also updated from php 7.4 to 8.2.  It appears to be after this update that we started noticing issues.

we are seeing issues related to the orderby drop down on top of the product grid.  If you select one of those(weight for example), it doesn't sort properly.  Also, after selecting a sort by option and then selecting a husky filter, it stalls at the "processing your selection" notice.

IF I reload the page though, the filtered results display so it seems to be related to the ajax call.

I've also added the compatibility function previously but it did not make a difference.

Quote from Alex Dovlatov on April 22, 2026, 11:53

Hello

Thank you for the details. I tested both scenarios on my end and recorded a video as well. I selected the Octaves #6 filter, applied it, then used the price sorting dropdown — ordering worked correctly. I also tested the reverse: applied sorting first, then the filter — same result, everything worked fine. (watch please video in my previous answer)

Could you please record a short video showing exactly what you are experiencing? I need to see the specific steps and the moment it breaks, because on my end I cannot reproduce the issue.

Regarding PHP 8.2 — our plugin has been compatible with PHP 8.3 for a long time, so that should not be the cause here.

Quote from dillonlara115 on April 22, 2026, 13:57

Hello,
I've added a video  showing the issues happening in a private window with caching disabled.

When I select a filter from the woof sidebar, it says "processing your selection" but hangs there.  The ajax call fails.  When I reload the page it displays the filter.

The order by drop down has the same issue, however, if we deactivate woof, the orderby dropdown starts to work.

Quote from Alex Dovlatov on April 23, 2026, 11:57

Hello

This turned out to be a completely different issue from what we were looking at before — and I found it just now while investigating https://clip2net.com/s/4nUO4wr

You have Cloudflare caching enabled, and it is caching your full HTML pages. HUSKY embeds a security key (nonce) directly into the page HTML. Once Cloudflare serves a cached copy of that page to a visitor, the nonce inside it is already expired. When the AJAX filter or sort request fires and sends that stale nonce to the server, the server rejects it — hence the "nonce error" and the request hanging. Reloading works because it occasionally fetches a fresh copy.

You have two options here.

Option 1 — keep Cloudflare caching but switch HUSKY to SEO links mode + disable AJAX mode use redirect mode. In this mode HUSKY does not use AJAX at all — filtering works via page redirects, so each filtered URL is a real cacheable page. Cloudflare will cache those filtered pages perfectly and there is no nonce involved. To enable this, go to HUSKY settings and turn on SEO links / redirect mode. One thing to keep in mind: when you add new products, they may not appear in the catalog immediately because Cloudflare will still be serving the old cached version of those pages. You will need to purge the Cloudflare cache after adding new products.

Option 2 — keep AJAX filtering but configure Cloudflare to bypass HTML caching for your shop and category pages. In your Cloudflare dashboard under Caching > Cache Rules, add a rule to bypass cache for URLs matching /product-category/ and your main shop page. This solves the nonce problem but you lose the Cloudflare HTML caching benefit on those pages.

Option 1 is generally the better fit for a WooCommerce catalog with Cloudflare — SEO links also give you indexable filtered URLs which is good for SEO.

 

Quote from dillonlara115 on April 28, 2026, 22:53

Hello,

We continue to have issues around this plugin.

Per your options above, we need to keep ajax for 2 reasons:

1. pagination prevents users from being able to compare sounds across all products.  The infinity scroll allows this to happen. Removing ajax and having pagination will stop that

2. There is little to no value in using the SEO links mode.  We do not want to index filtered shop pages.  This gives duplicate content errors, and both the h1 and meta description would likely be same for these filtered pages so we do not want to use SEO links mode, unless I'm missing something.

What we would ultimately like to understand though is that we did not have any conflicts with this plugin until 1-2 weeks ago, however, Cloudflare has been active for over a year.  Why is this an issue now?  Our store owner uses these filters daily and can confirm that they were working previously.  can we please add our shop owner to this support ticket?