WAIT: Bricks + TranslatePress = No search results

Bugs
1

Bricks version: 1.5.2

Hi, when using Bricks Builder with TranslatePress, I get no (or minimal) search results in the secondary language. Main language works OK, it appears to show the same results as without Bricks. For other languages the search only shows results which have matching URL slug with the search term. The slug has to be a 1:1 exact match with the search term.

The slug, is of course too, translated with TranslatePress. This seems to be the only piece of translations that WP search appears to see, when Bricks is in use. No other search results are shown. The WP search acts differently for the main language as for other languages when Bricks is activated.

I reproduced the issue by installing a fresh WordPress with only TranslatePress. No issues, translated content can be searched (and found) in 2nd language. As soon as I install Bricks, the search works normally only when browsing the site in the main language, but second language is missing more than 90% of results.

My temporary workaround for now has been to use the Relevanssi plugin which includes post tags in the search. This seems to work for pages/products/articles with Bricks + TranslatePress, but is of course not an sustainable option, as I’d have to enter the whole content (from Bricks) as tags. If there’s a trick or treat I could use here, I’d be super thankful.

EDIT: I have tried, with no results:

  • using the “&trp-form-language=fi” parameter in the URL
  • A fresh WP install with only TP (and Bricks and TP)
  • Deactivating ALL plugins except Bricks and TP
  • Asking for help from TranslatePress, but they say it’s a problem with Bricks since it works without Bricks
  • I have enabled (and re-enabled) “Query Bricks data in search results” in Bricks settings
  • Several search enhancement plugins, Relevanssi being the only which seems to help a tiny bit

SCREENSHOTS:

2nd language search without Bricks.
Search results don’t show up entirely, but Muki is the title of the product I was looking for and can be seen as a result in the bottom of the screenshot. The search works and finds results from post title and content.

without bricks
without bricks2816Ă—1564 180 KB

2nd language search with Bricks. 0 results. Doesn’t find results from post title or content.

with bricks
with bricks1950Ă—1138 219 KB

Further details:

WP Version: 6.0.2

TranslatePress - Multilingual: Version 2.3.7
TranslatePress - Business: Version 1.2.2

Site Language: en_US

Translated languages: fi (or any)

Permalink structure: /%postname%/

1 Like
2

Nothing? :face_with_raised_eyebrow: I contacted TranslatePress support and (as already confirmed above) the issue is with Bricks, not their plugin. TP doesn’t cause search issues with any other theme. I’m suggesting it is a conflict with how Bricks shows the results.

3

Hi kautto,
Sorry that I have not answered yet. Problems with third-party plugins are always difficult to reproduce, especially if you have never used the plugin.

We already have a report on another TranslatePress issue and will look into it as soon as possible.

Best regards,
timmse

4

there is a setting in bricks. not sure whether it matters.
image

5

Would it be of any help, if I created a separated installation for you with login details?

6

Yeah, thanks, I do have tried this though, with no effect :slightly_frowning_face: (see op)

7

I think both bricks and translatepress would modify the search code and create conflicts. Translatepress is based on string translation and causes different situations in many aspects. Maybe using WPML or Polylang can avoid this issue.

8

Yeah, it seems so. I don’t know why either needs to modify the search (esp bricks, what benefit does it bring). But as they both have options/adjustments for search, they both most likely do modify the search, which most likely is the cause for the search bug.

If you try TranslatePress once, you will never go back. Anything else feels horrible and slow now. I just killed my Polylang Pro and WPML subscriptions. Before Bricks I haven’t had a single problem with it :slight_smile:

1 Like
9

The main difference is that WPML and Polylang would create a duplicated post/page for each language while TranslatePress only stores the strings translation of the original post/page in its’s own database table and then output the translation dynamically when other languages requested, and thus posts/pages of other languages do not have their own actual posts/pages.

The largest drawback is that you cannot simply output the posts/pages of another languages except for the original language, as they don’t exist actually. This is very bad for management of a large website in the long term. So I have seen agency abandon TranslatePress only because of this issue.

1 Like
10

Hey @kautto,
Please send login credentials and a link to this thread to help@bricksbuilder.io.

A short screencast explaining how Translatepress works and where/how the problems occur would be very helpful since none of us have ever used it.

Best regards,
timmse

11

Great idea, I just did that! You should have the log in details and video in your email.


This goes a bit off the topic, but: The magic of TranslatePress lies exactly within that feature. (Yes, I call it a feature :joy:)

When you build webpages for SME’s like I do, localization, at least in heavy measures, is not needed. A translation is enough. And when translating, having separate pages for each page’s each language is definitely a pain, not a relief. Think of having 5, 10, 15 languages? A 10-paged website will take much less time to translate if you do it within one tab, one visual (WYSIWYG) translation editor, not having to do every page’s every translation in a separate tab, using a non-WYSIWYG- editor. I dare to claim we cut translation times by at least 50%. That’s why this agency abandoned everything else than TranslatePress.


I don’t think it’s a matter of having a large website. I do understand this for large corporations, for which a different country wouldn’t mean just translations, but different pages, topics, content, pictures, links… etc. In such case, we’re not just talking about translating strings of text, we’re talking about localizing the UX for a different culture. TP can do some of that within one page’s translations: like replace links, imgs, vids etc, but of course can not rearrange the layout or such. If you need that, you’ll just create two different pages with TranslatePress and then link them together. :man_shrugging: But if you need to do it for most of the pages, I get it, don’t use TranslatePress.

2 Likes
12

Dear @kautto

Sorry to reopen this topic.
May I know if you have tried our latest version of Bricks?
In 1.9.2, as long as setting the Search query as “is main archive”, the Search result should works properly now.
image

Regards,
Jenn

13

I have the same problem. Would love to know if anyone figured out a solution to make Brick Query Search work with the secondary languages.

14

thats true…we can not move to new tech-stack, relaunch with TP…you must really copy past by hand EVERYTHING…its horrible…rest is very good…someone must write a plugin doing that…

15

Its 2025: this doesnt help…i tried it with own PHP enhancement but no luck…