Home›Support›English Support›[Resolved] Filter Options Not Working on Translated Archive Page (JetEngine Custom Fields)
[Resolved] Filter Options Not Working on Translated Archive Page (JetEngine Custom Fields)
This thread is resolved. Here is a description of the problem and solution.
Problem:
The client is experiencing issues with translated filters on the English archive page of a site built with JetEngine and WPML. Specifically, filters for Weekday, Age group, and Teacher either show partial values, no values, or the values do not return the correct results when selected. The Meta Field keys are identical in both languages, and translations are correctly added in the WPML editor.
Solution:
To resolve the issue with the Weekday filter, we: 1) Changed the Weekdag field ID of the Course post type from 'weekdag' to 'weekdag_course'. 2) Updated the query variable of the Weekdag filter from 'weekdag' to 'weekdag_course'. 3) Set the 'weekdag_course' field to Copy in WPML>>Settings>>Custom Fields Translation. 4) Reverted the translations of Weekdag field option values in String Translation — the values should be the same in both languages (e.g., "woensdag"). 5) Updated the Weekdag field values for the first nine Course posts. 6) Updated the translations for those posts.
For other filters like Age, Daypart, Duration, and Teacher, follow similar steps. Ensure that the field settings are adjusted to either 'Copy' or 'Translate' as appropriate, based on whether the field values need to be the same or different across languages. You do not need to rename all custom field IDs unless they conflict with others.
If this solution does not apply to your case, or if it seems outdated, we highly recommend checking related known issues at https://wpml.org/known-issues/, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If issues persist, please open a new support ticket.
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Hey Bigul, I know you've said that I should wait but I'm already waiting for another week now. My client (site's owner) wants to go live but we can't this way. I'm hoping this site is a priority at your end?
Sorry for the late response. It was a bit complicated than expected. So we were waiting for an expert opinion from our compatibility developers.
Please check the English Course page now and let us know your feedback. We can filter it by Weekdays (Saturday and Wednesday) after the following steps: hidden link
1) Visit WPML>>Settings>>Custom Fields Translation
2) Search for the *weekdag* field
3) Set *weekdag* field as *Copy* and save the changes
4) Visit WPML>>String Translation
5) Translate the Weekdays strings from Dutch to English
6) Visit Smart Filters and open the *Weekdag* filter for editing
7) Set the query field as *weekdag* in both languages and save the changes
8) Open the Course a couple of course posts for editing in the Dutch language and update them
9) Update its English translation
Please try similar steps for the other filters as well, and check if they are working as expected.
You may need to manually select the Teacher value for English Course posts because you are using the Docenten post type, and its posts are already translated into English. As a result, the post IDs will be different in both languages.
Thanks for the reply. It seems to (kind of) work. But not everything. The translated word is in Dutch now on the English pages, which is not good (see screenshots 1 and 2).
And besides that: do we need to manually add all these filter items now? That's impossible to do, that's so much work. Why were the other filter items all automatically translated? We don't want all this extra work because it's already taking so much longer then expected because of this issue...
Thank you for the updates. Please check the attached image. Currently, you are using Custom Fields, Taxonomy, and Post Type for filtering the posts. When using Taxonomy terms and Posts for filtering, their IDs will differ in the secondary languages. That’s why we need to select them manually in the secondary language posts.
Also, we need to make sure that the query variable (for example *weekdag*) is the same in both the Dutch and English language filters.
We will further investigate why the Weekday field value is not showing the translation for the English posts and get back to you soon. Please wait.
I get that but that doesn't explain why not all filters are visible on the front-end now. See the screenshots for what I mean.
Also, there are double filters on the English page which isn't how it should be. And we shouldn't be putting everything in there manually I suppose, right?
Thank you for the updates. I am consulting with our compatibility team for an expert opinion now. We have a request, please upgrade to the latest version of WordPress and plugins after a full site backup {mandatory} because it will be beneficial in our further debugging.
Bigul, I know I have to wait but we're losing our patience a little bit. Are you guys really working on our problem? Because every time it takes so long in between.
Sorry for the delay. We are still actively working on this issue and have identified the main cause of the conflict.
It appears that a separate custom post type, "Events", is using the same field name/ID (weekdag), which is likely causing the issue. Similar to how WordPress custom fields (e.g., ACF fields) work, it is important not to assign the same name to different fields across post types. While the label “Weekdag” can remain the same for display purposes, we recommend using unique field names or IDs, for example, weekdag_course and weekdag_event, to avoid such conflicts.
As a next step, we kindly request you to take a full backup of the site. We would then like to proceed with making the necessary changes to the Course post type and its template to address this issue.
Please refer to the following screencast for more details: hidden link
I performed several rounds of testing on your site after applying the following changes and upgrading to WordPress 6.8.1. As a result, the Course Archive filtering is now working as expected for the Weekday filter in English:
1) Changed the Weekdag field ID of the Course post type from weekdag to weekdag_course.
2) Updated the query variable of the Weekdag filter from weekdag to weekdag_course.
3) Set the weekdag_course field to Copy in WPML>>Settings>>Custom Fields Translation.
4) Reverted the translations of Weekdag field option values in String Translation — the values should be the same in both languages (e.g., "woensdag").
5) Updated the Weekdag field values for the first nine Course posts listed here: hidden link, since we changed the field ID to weekdag_course.
6) Updated the translations for those posts.
Please refer to the attached screencast for more details. hidden link
However, the translation of the Weekdag field is still not appearing correctly in the Course Archives in English (see attached image). We are continuing to investigate this.
Currently, most of the Select fields in the Course post type are set to Translate instead of Copy. Additionally, you’re using the same string for both the select option and its value (e.g., duur). This setup can interfere with correct filtering and translation. Therefore, we recommend adjusting the fields configuration, like the *Weekdag* field, to ensure proper translation, especially for filtering purposes.
Please check the following screencast linked and the doc for more guidance, and let us know your feedback.
Thank you for the detailed update and your help so far.
I just want to clarify a few things to be sure I fully understand the next steps. From what I gather, the Weekday filter now works thanks to your adjustments — that’s great.
Could you please confirm:
1. What exact steps do I need to follow to make the other filters (like Age, Daypart, Duration, and Teacher) work the same way?
2. Do I need to rename all those custom field IDs (like you did for "weekdag" to "weekdag_course")?
3. Will you assist in applying those changes to all existing filters and posts, or do I need to do that manually?
4. Lastly — when can I expect those changes or updates to be implemented on your side?
Thanks again, looking forward to getting everything running smoothly.
Thank you for the updates. Please read the following and let us know your feedback.
1) Yes, you have to follow the same steps for all the *Multiple Choice/Select fields* (for example: Daypart & Duration) to get the expected results
2) You don't have to rename all the Custom Field IDs. The field ID should be a unique value. So you only have to rename it if it is used by another field (for example: Event Weekdag - weekdag).
3) We made changes for Course - Weekdag field and happy to clear all your doubts. You have to correct it manually because the data is stored in multiple tables in the database.
4) We have limitations to update all your posts & settings. Becuase you have 100s of posts and multiple post types. The custom field values of each post are stored individually: https://codex.wordpress.org/Post_Meta_Data_Section
The translation of the Weekdag field now appears correctly in the Course Archives in English after the following changes. Please see the attached images for more details, and this doc for more details: hidden link
After reviewing the source code, our compatibility team found that the field was pulling the value ("maandag") instead of the label ("Maandag"). This is why it wasn’t translated into English — only labels should be translated, not values.
This issue didn’t occur with other fields because this one is a multiple-choice field that uses a value:label format.
To fix it, we changed how the field is displayed in the listing. We used a Dynamic Field widget that correctly shows the label from the glossary. We also updated the styles of this field (like the Lessons field).
We edited the following template to achieve this:
hidden link
--
Thanks!
Bigul
Manage Cookie Consent
We use cookies to optimize our website and services. Your consent allows us to process data such as browsing behavior. Not consenting may affect some features.
Functional
Always active
Required for our website to operate and communicate correctly.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
We use these to analyze the statistics of our site. Collected information is completely anonymous.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
These cookies track your browsing to provide ads relevant to you.