Problem:
When saving Automatic Translation settings in WPML (and other plugin settings like Hostinger Tools), client received a "Some error occurred" message. The settings were not being saved.
Solution:
During the investigation, I found that .htaccess file contained a custom "Trailing Slash Redirect" rule that was interfering with WordPress REST API requests.
This rule was forcing all URLs to end with a trailing slash (/), which caused:
- REST API POST requests (e.g., /wp-json/wpml/v1/save-automatic-translation-settings) to be redirected with a 301 status to the same URL with a trailing slash
- The browser converted the POST request to a GET request during the redirect (standard HTTP behavior)
- The REST API endpoint returned a 404 error because it doesn't accept GET requests at that URL
This affected all plugins using the WordPress REST API, not just WPML.
I modified the existing trailing slash redirect rule in .htaccess file to exclude REST API paths (/wp-json/).
Problem: You are experiencing an issue where WPML is missing some records in the languages tables, which prevents it from fully working. Despite following the suggested troubleshooting steps like clearing language information and repopulating languages, removing ghost entries, fixing terms and taxonomy relationships, setting language information, assigning translation status to duplicated content, and fixing post type assignment for translations, the problem persists.
Solution: If you're facing this issue, we recommend you try the following steps after taking a database backup: 1- Open your database manager, for example, PhpMyAdmin. 2- Navigate to the "wp_options" table (note: 'wp_' is a standard prefix, yours might be different but the table name will be similar to xx_options). 3- Execute the following SQL query to search for the 'icl_admin_messages' key:
SELECT *
FROM `wp_options`
WHERE `option_name` LIKE '%icl_admin_messages%'
LIMIT 50;
4- Delete this key from your database. 5- Clear your cache, refresh your dashboard, and check if the message has disappeared.
This solution might be irrelevant if it's outdated or not applicable to your case. 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 at WPML support forum for further assistance.
Problem: The client was unable to translate the name of a product variation in a WooCommerce site using WPML. Despite the translation being completed in the Advanced Translation Editor (ATE), the variation name still displayed in the original language on the front-end.
Solution: We identified that the issue was related to a custom function in the theme's
functions.php
file, which incorrectly handled language information and prevented translations from being applied. We modified the function to ensure it checks for valid data before proceeding. Here's the corrected code snippet:
if (function_exists('wpml_get_language_information')) {<br /> $lang_info = wpml_get_language_information($post_id);<br /> // Check if we got a WP_Error<br /> if (is_wp_error($lang_info)) {<br /> error_log('WP_Error encountered in wpml_get_language_information: ' + $lang_info->get_error_message());<br /> return; // Stop execution if there's an error<br /> }<br /> <br /> if ($lang_info['language_code'] !== 'en') {<br /> return;<br /> }<br />}
After applying this fix, the product variation name displayed correctly in all languages. If this solution does not resolve your issue, or if it seems outdated or irrelevant to your case, please check related known issues at https://wpml.org/known-issues/, verify the version of the permanent fix, and confirm that you have installed the latest versions of themes and plugins. We highly recommend opening a new support ticket if further assistance is needed. You can do so at WPML support forum.
