Problem: The client was facing an issue where products available in only one language were still showing the language selector for other languages. When trying to access the URL directly or clicking the language selector, a 'Too many redirects' error occurred. Solution: We suggested checking the WPML > Settings > Post Type Translation to ensure that "Products" was set to "Translatable – use translation if available or fallback to default language". If the setting was already correct, we recommended toggling it off and on again, as this resolved the issue for the client.
If you're experiencing similar issues, we recommend checking your WPML settings and ensuring they are configured correctly. If the problem persists, it might be due to an outdated solution or a different underlying issue. We highly recommend visiting related known issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If none of these steps work, please open a new support ticket.
Problem:
If you're experiencing critical errors with messages indicating that the 'Maximum execution time of 180 seconds exceeded' in your WooCommerce logs, and these are linked to WPML, we recommend taking the following steps to isolate and resolve the issue.
Solution:
First, ensure you create a full backup of your site. Then, proceed with the following troubleshooting steps:
1. Update any outdated plugins or themes.
2. Flush any cache memory that might exist on your site.
3. Deactivate all plugins, including WPML ones.
4. Activate a default WordPress theme, such as Twenty Twenty.
5. Reactivate the WPML plugins, WooCommerce, and WooCommerce Multilingual & Multicurrency.
6. If the issue is resolved, begin reactivating your theme and then the other plugins one by one. This will help you identify the plugin or theme causing the conflict.
If you prefer not to perform these steps on your live site, consider creating a staging site to test these changes without affecting your production environment.
Please note that the solution provided might be irrelevant if it's outdated or not applicable to your case. If after following these steps the problem persists, we highly recommend checking related known issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. If you still need assistance, please do not hesitate to open a new support ticket with us.
Problem: The client reported an issue where the block titles in the Gutenberg editor were displaying in Swedish when adding new blocks to a Swedish page, despite the admin language being set to English.
Solution: Our supporter clarified that when using the WPML translation editor to translate a page and temporarily switching to the second language (Swedish) to edit the page manually, it is expected behavior for the field label in the newly added block to display in Swedish. To display the translation field label in English, the client should enable the option 'Set admin language as editing language' under User > Profile. However, this change would be lost if the WPML translation editor is used to update the translation page again. The correct workflow should be to edit the page in the original language (English), save the changes, and then update the translation in the WPML translation editor.
Lastly, we informed the client that it is not possible for the translation field label in the new block to display in English if the page language is Swedish. If the client wants the block info to display in English, they should go to ACF, edit the block, change all field labels and other info to English, and not translate them in WPML > String Translation.
Please note that this solution might be irrelevant due to being outdated or not applicable to your case. If so, 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 the issue persists, please open a new support ticket with us.
Problem: The client's custom post type field is not displaying translations on the frontend. Solution: We recommend ensuring that if you are selecting a taxonomy or a custom post type in your code, you must also select the translated version of that taxonomy or custom post type. If the slug is translated for the post type or taxonomy, but not updated in your code, this could be the reason why the translations are not appearing on the frontend.
If this solution does not apply to your situation, or if it seems outdated, we encourage you to open a new support ticket. We also highly recommend checking the related known issues, verifying the version of the permanent fix, and confirming that you have installed the latest versions of themes and plugins. For further assistance, please visit our support forum.
1. Case: Same Name Across Field Groups:
In our setup, we utilize blocks comprising various ACF field groups. Each block is treated in its unique namespace by ACF, and we've assumed a similar approach by WPML. It appears unusual that a distinct name for each field is necessary. Could you confirm if WPML requires unique names for every field within a block?
2. Case: Repeater Fields:
When employing repeater fields, the same field and name are reused iteratively. I'm seeking clarification on how WPML distinguishes and handles such scenarios. What distinguishes this case from using the same name on a group-type field and a sub-field within that group?
Solution:
In the case of repeater fields, field names are prefixed with parent field names. So ACF and WPML handle the field names correctly.
In the case of normal fields, all field names should be unique in different groups if they are being used on the same object. The same recommendation from ACF:
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.
