Problem: The client reported two main issues with their WPML setup on a WordPress site using WooCommerce, Elementor Pro, and the WoodMart theme. First, the main navigation menu was not rendering on translated pages across 10 active languages. Second, the menu admin UI displayed empty items despite a record count indicating the presence of items.
Solution: We addressed the issue in several steps: 1. We instructed the client to perform basic troubleshooting via WPML > Support > Troubleshooting, which included clearing WPML cache and fixing terms count. 2. For the mega menu not displaying correctly, we set specific custom fields related to the mega menu feature to 'Copy' under WPML > Settings > Custom fields section. This ensured that the mega menu settings were consistent across all languages. 3. We corrected the settings for the '_menu_item_object_id' custom field from 'Copy' to 'Don't translate' to prevent incorrect item relationships across different languages. This change was crucial for maintaining menu integrity when translated. 4. The client was advised to manually delete and re-add menu items in the non-English menus and synchronize them with the original menu.
These steps resolved the issues with menu visibility and functionality in the admin UI and on the frontend across all languages. For further details on translating custom fields, please refer to this documentation.
If these solutions do not resolve your issue, or if they seem outdated or irrelevant to your specific 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 problems persist, please open a new support ticket.
Problem: The client is experiencing high translation costs due to WPML translating backend/admin strings, which are not necessary for their site's frontend. They need a way to disable backend/admin translations to save on translation credits. Solution: We recommend excluding specific backend/admin string contexts from automatic translation to prevent unnecessary credit usage. This involves identifying the contexts that are not required for frontend display, such as 'woocommerce-wc-admin-app', 'litespeed-cache', and others listed by the client. To implement this, you can modify the WPML String Translation settings to exclude these contexts.
Additionally, to address issues with menu items on translated pages not functioning correctly (e.g., the 'Products' menu item URL changing to '/es/#'), we suggest adding a code snippet to your theme's functions.php file or a custom plugin. This code will ensure that anchor-only URLs (like '#') are not translated, preserving their functionality across different language versions:
/**
* Skip URL conversion for anchor-only URLs (# or #something)
* This prevents WPML from converting # to /es/# on translated pages
*/
add_filter( 'wpml_skip_convert_url_string', function( $skip, $url, $lang_code ) {
if ( strpos( $url, '#' ) === 0 ) {
return true;
}
return $skip;
}, 10, 3 );
Please note that this solution might be outdated or not applicable to your specific case. If these steps do not resolve your issue, 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 problem persists, please open a new support ticket for further assistance.
Problem: The client was experiencing issues with WPML's 'Different languages in directories' mode on a WooCommerce site using LiteSpeed Cache. The language URLs (/es/, /nl/, etc.) were conflicting with media attachment slugs in the database, causing redirects to incorrect media files or error pages. Solution: We resolved the issue by renaming the conflicting media attachment slugs ('es' and 'nl') that were intercepting WPML's rewrite rules, allowing the directories to route correctly. However, since the site was migrated from TranslatePress, all translations need to be rebuilt, and pages like /es/, /de/, /fr/ etc. are returning 404 pages due to the absence of translated content. To address this, the client wants to connect their own DeepL API key for automatic site translation. In WPML → Settings, after selecting 'Different Engine' and activating DeepL as the translation engine, the field to enter the DeepL API key should be visible. 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 further assistance is needed, please open a new support ticket at WPML support forum.
