NO BUG: Query Filter index works only in one WPML language at a time

Hi Bricks team,

I am experiencing a reproducible issue with Bricks Query Filters, WPML, WooCommerce, and ACF taxonomies.

The filters work in only one language at a time:

  1. I regenerate or repair the Bricks filter index.

  2. The filters work in English, but not in German.

  3. I update the German translation through WPML ATE or resave the filters.

  4. German starts working, but the English filter options disappear or show a count of zero.

  5. Regenerating the index fixes English again, but German stops affecting the query loop.

In the affected language, the filters may still be displayed and selectable, but clicking them does not change the query results.

Another unusual observation: duplicating any filter temporarily makes all filters work in the current language. Deleting the duplicate breaks them again. Keeping a hidden duplicate is not a reliable workaround because the other language then stops working.

I have already:

  • Regenerated the filter index several times

  • Completed all pending index jobs

  • Used “Fix corrupted database”

  • Removed and recreated all index jobs

  • Corrected WPML taxonomy term counts

  • Cleared the WPML, CDN, and browser caches

  • Disabled the performance/cache plugin

  • Checked the WPML translation settings for Bricks custom fields

None of these steps allows both languages to work simultaneously.

I found several similar reports, some dating back one to two years:

This appears to be a recurring problem rather than an isolated configuration issue. It currently blocks the launch of a multilingual WooCommerce website.

Could you please prioritize the issue and confirm whether the filter index is being overwritten or incorrectly scoped when switching or updating languages?

Additional reproducible test:

  1. I completely deleted the German translation of the Shop page.

  2. I regenerated the Bricks filter index and waited until all indexing jobs were completed.

  3. With only the English Shop page present, all filters worked correctly.

  4. I created a new German translation using the WPML plus icon.

  5. I completed the translation through WPML Advanced Translation Editor and set it to 100%.

  6. I did not edit, duplicate, resave, or reindex any Bricks filter afterward.

Result:

The English Shop page continues to work, but the filters on the newly created German Shop page do not work.

The filters are displayed and can be selected, but they do not affect the product query loop.

This provides a consistent reproduction: the default-language filters work correctly, but a newly created WPML translation does not receive a functional Bricks filter index or a working connection between the translated filters and their target query loop.

edit:/
Additional finding: Setting _bricks_page_settings to “Copy”, as suggested in a related WPML/Bricks thread, caused the translated homepage content to disappear completely. Changing _bricks_page_settings back to “Don’t translate” immediately restored the translated homepage. Therefore, the suggested custom-field configuration is not a valid general workaround and can break translated Bricks pages.

Thanks for the detailed report. This is close to previous WPML/query-filter indexing cases, but we need to inspect the current setup before confirming whether this is the same issue or a new regression.

Please send temporary access to a staging or development copy to help@bricksbuilder.io and include a link to this forum thread.

I no longer have a site to test on, since I’ve now switched my site to the non-ATE version.

It works now.

And that confirms once again: ATE + Bricksfilter doesn’t work.

Well, not giving us a chance to check your specific problem in your setup doesn’t necessarily help us solve any potential issues. Please get back to us when you’re able to reproduce the problem again.

Surely you have development environments where you can reproduce this?

It’s just Bricks + WPML in ATE mode. Nothing complicated.

I think it’s in your best interest to fix this issue.

Let me repeat:

We can only do that on your installation. “It’s just x + y” is rarely the case, especially with complex plugins like WPML, and complex features such as filters.

I can reproduce what appears to be the same issue on a staging site.

Environment

  • Bricks 2.3.12

  • WPML 4.9.5

  • ACF Pro

  • Bricks Query Filters with Custom Fields Integration enabled

  • Two languages: Dutch (default) and German

Issue
Query Filters work inconsistently between WPML languages. A filter set may work in German but not in Dutch, or vice versa. The query results themselves are available in both languages, but filter options/counts may be missing.

Regenerating the complete Query Filter index does not reliably fix the issue.

Interesting behaviour
Duplicating an existing filter element, updating the filter index, saving the page, and then removing the duplicate can make the filters work again. This can affect the language in which the filters currently work.

We currently have a staging site where this issue can be reproduced and can provide temporary admin access if needed.

Hi David,
Thanks for providing a current reproducible setup.

Please email temporary staging admin access to help@bricksbuilder.io, include a link to this forum thread, and identify the affected Dutch and German page URLs. Please keep the staging site in the failing ATE configuration so the behavior can be tested as described.

Thank you for your quick reply. Details just send to you.

Hi @David013

Based on our email conversation, the custom fields translation set on your website is causing the filter index to be incorrect.

Resetting it back to “Don’t translate” solved the issue.

Thank you very much for the prompt reply and fix. :flexed_biceps:

_bricks template settings were left on copy since this was the mandatory and locked setting.

Hi @David013

I just logged into your staging site again, and I can see the _bricks_template_settings is not locked.

The only field locked should be _bricks_template_type

If _bricks_template_settings was locked on your live site, you might need to deactivate plugins and investigate which plugin’s setting locked it.

My apologies, you’re right. I changed the settings as you advised. Works like a charm.