There was a change with 1.9.4 and what I read it fixed urls issues with translated search results, but broke the search results for user that set:
Hide URL language information for default language
Remove /language/ in pretty permalinks
I have to check on a backup but I’m 99% sure I tested it and it worker before 1.9.4.
The second language page can be directly reached through address via: https://example.com/en/?s=books - So the second language search result page does work in general.
But using the search element one gets a 404 everywhere and for every search input now.
And I’m pretty sure it is because Bricks puts the start page url into the search result url like this as this is the url shown for the 404.
home-en is the start page url of the second language. Is there a quick fix for this?
//EDIT: Yes, it’s an issue with 1.9.4. I replaced your searchform.php with the one from version 1.9.1. Now no 404 anymore but the results shown are in the primary language.
This 404 has to with this new line in the searchform.php: <form role="search" method="get" class="bricks-search-form" action="<?php echo esc_url( home_url( '/' ) ); ?>">
//EDIT2: I fixed this issue with the help of Chatty… I replaced <form role="search" method="get" class="bricks-search-form" action="<?php echo esc_url( home_url( '/' ) ); ?>">
with <form role="search" method="get" class="bricks-search-form" action="<?php echo esc_url( home_url( '/' . ( function_exists('pll_current_language') && pll_current_language() != pll_default_language() ? pll_current_language() . '/' : '' ) ) ); ?>">
Now the correct second language search results and page will be shown until the next update breaks it…
The issue is still present with 1.9.5. I see there were changes made to the template but unfortunately not at all for the Polylang issue.
I still need to modify the template like I described above… For some reason executing a search on the secondary /en/ language on the shop page leads to a 404 because the result page sets /home-en/, which is the url slug for the English homepage, in the url path.
Being in
//EDIT: Ok, I need to correct my statement. I tested the stock 1.9.5 searchform.php and the issue is present but only for the shop page of the secondary language. I guess here it gets complicated.
There are to shop pages for each language. Both have the same slug “shop”. And since the shop archive page works different to how Elementor does it I needed to create shop archive templates for each language… So there seems to be an issue for the search result page and what the parent slug is for the secondary language shop page. The search query seems to think it must add /home-en/ to the url which is never showed according to the Polylang settings. Again this issue is not present for other translated pages for some reason.
//EDIT2: Well, I have spotted that the search element has an action url field now. I entered the secondary language parent url in it and now the search resuls work without modifying the template. So the issue is fixed. To be honest a simple solution for a complex problem. Intuitively I must have thought as the issue appeared that Bricks acknowledge the home urls for each language by itself and there would be no need to modify the Action URL parameter.
The search element is still not working with Polylang in Bricks 1.9.7.1. On the DE page (which is the primary language) the user gets shown all language search results. Where searching from the EN page the user gets only the correct EN search results.
Will this be fixed? This issue is present since December 2023.
I have seen your report a few days back already. I decided due to several issues back then in December to not use infinity scroll till the issues are sorted out. Jenn from Bricks helped me to find the culprit for the 401 error I was getting with infinity scroll which was a complicated find. To shorten it down. I do not have your setup and use pagination. With AJAX pagination there is no such issue like yours. Unfortunately there are a few hiccups with Polylang and Bricks. But I hope they get it sorted. I rather not use the WMPL performance hog. At least in my opinion I can not grasp why WP doesn’t offer an official core solution for translation already a decade ago. The internet is not just your front garden.
Great to hear that you could replicate this. I have not found a temporary fix to this. It seems like a running target as with prior versions of Bricks the primary lang search results were correct but the secondary was mixed. Now its the opposite.
I just tested 1.9.8 on the staging and this is no fixed for me here. Still the search results for the primary language show also the secondary language post/products.
Additionally to that with 1.9.8 switching languages on shop and products archives is broken. Nothing happens when trying to switch… I guess need to open a new thread for the latter?
Let me know your final URL when search a string from your secondary home page.
1.9.8-beta should generate this xxxx/en?s=YOUR_SEARCH (if en is your second language)
Kindly provide admin access for us through email to check this Search element issue.
example.com/?s=product = no 404 but primary and secondary language results shown
For the secondary /en/ start page it is: example.com/en?s=product = no 404 and secondary language results shown
From the shop page primary language it is:
example.com/a-not-with-the-home-page-related-page-appears/?s=product = 404 and a page will be used in the url that is not related to the home page in any way
I send an email with screen captures
//Edit: Ok, I found the cause for that issue example.com/a-not-with-the-home-page-related-page-appears/?s=product = 404 and a page will be used in the url that is not related to the home page in any way
Back then for an older version of Bricks I was recommended to use the language slug also for the primary language which is /de/ for the action url. this is obviously an issue now. Once removed this one issue is gone. But still primary and secondary language results shown.
