Forum Replies Created
-
Posts
-
2. In that case you are looking for these filters: https://i.imgur.com/9qDGVwv.png
Products use a different taxonomy 🙂
I still can’t replicate on any of our computers, every time I see the same exact output for all the browsers.
May I ask what is the operating system?
It was 3 different files where I had to add a new function and an exception for this specific character combination.
I have already implmented this change via the issue tracker so the upcoming release will include it too 🙂
Thank you!
I made the changes via FTP. I could not test as the site requested .htpassword and the username/password combo didn’t work for it.
Anyways only one step is left, can you please re-create the index on test site? If all goes right, now every character should be converted from “Å“” to “oe” format after indexing. If it works, then you can safely push the plugin folder to production.
Hi Romain,
Thank you for the details it helps a lot!
The search override feature was disabled. That means the default WooCommerce results were displayed. The keywords must have matched somewhere in the content or a custom field – it is not possible to search the domain name, it is very likely stored somewhere.
Anyways, I have enabled the override, now you should start seeing more relevant results.
I also recommend updating the plugin sometime because it is outdated.
Hi!
1. In the custom field filter the value which is assigned wit the two stars ** is going to be selected by default from the list. That is basically an “empty” selection, you can edit the text of that as you need it.
2. It is not showing because you don’t have any post tags created yet, see: https://i.imgur.com/Y4XLVjN.png
I guess the taxonomy something different for what you are looking for.Then I remembered correctly.
That should actually resolve the problem, the action you need to add to the list is:
ajaxsearchpro_searchHi,
The error is issued because the search response data is modifed – I assume weglot tries to translate everything “on the fly” and also hooks into the request response. However the response data contains JSON structured information, which should not be changed, otherwise it is broken and can’t be decoded. JSON is normally used with ajax requests, so I am not exactly sure why would the translator try to change the XHR response data. I guess if the XHR response format is not exclicitly JSON then it will just automatically apply.
I believe we tried to solve this some time ago, and if I recall correctly, then the main bascially unsolvable issue with this plugin was, that it translated in real time during output. I belive the translations weren’t stored as separate post type objects, but additional data somewhere external, which was not searchable.
I recall someone had a similar issue, but then he never responded. The only possible solution to this is to either add exceptions – if possible in a form of regular expressions, so that some string contents including the JSON data are left as is without translation. I don’t know if weglot has a feature like that, I am not familiar with it.
