Background of the issue:
I'm trying to build a separate French navigation menu on my bilingual WordPress site using WPML. The default language is English, and the secondary language is French. I have followed various troubleshooting steps and documentation, including WPML Troubleshooting tools, Menu Sync documentation, and advice from a WPML chat transcript.
Symptoms:
Translated menu items disappear after saving, and I am unable to build a French menu. The same issue affects my English footer menu. Additionally, when creating a menu in French, it switches back to English automatically after clicking 'Create Menu'.
Questions:
Why do translated menu items disappear after saving?
Why does the menu switch back to English after creating it in French?
How can I successfully build a French navigation menu using WPML?
Thanks again for your help and for escalating the issue.
After following your video and testing the Menu Sync feature, here’s a full and clear summary of the situation:
⸻
🔄 What I’ve tested:
1. I deleted all existing menus and tried to rebuild a clean French navigation from scratch.
2. I used Menu Sync — it partially worked, displaying some translated items.
3. But then I tried to manually add two missing pages: “Voyage” and “Depuis notre camp de base”.
• As soon as I clicked “Save Menu”, the entire French menu disappeared again.
4. I then tested manual menu creation in English for the footer.
• I tried to add “Terms and Conditions” and “Blog” (both correctly translated in English).
• Same issue: as soon as I save, the menu resets or removes the items.
⸻
❗️Problem recap:
• Manual menu editing is broken in both languages, not just in French.
• I cannot add any pages to a new menu, whether in English or French.
• Even pages that are published, correctly translated, and accessible on the frontend (like “Terms and Conditions”) refuse to stay in the menu after saving.
• When I try to create a new menu in French, it also automatically switches back to English upon saving.
⸻
🔍 Additional notes:
• You mentioned a possible link to WooCommerce, but I’m using it in a standard setup.
• WPML claims full compatibility with WooCommerce on your official website — so I don’t see any unusual configuration on my end.
• I am hosted on WordPress.com, which limits access to wp-config.php, but you were already able to install Check Conflicts and Duplicator.
⸻
🔧 Suggested next step:
You are welcome to try creating a menu yourself in my dashboard:
• Try building a French menu and adding “Voyage” and “Depuis notre camp de base”.
• Or try building an English footer menu and adding “Terms and Conditions” and “Blog”.
You should be able to reproduce the issue directly — and I hope this will help your second-tier team understand where the problem is rooted.
Thanks again for your time and support. I’m happy to help with more tests if needed.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Madrid (GMT+02:00)
Hi there!
I have escalated again to the second tier.
Also what I have discovered that on my local copy of your site it is working properly, so that tell us that it is related to wordpress.com so we are investigating.
To help me understand what’s working on your side — and to potentially forward the issue to WordPress.com support — would you mind recording a quick video of the following actions on your local copy?
1. Create a new English footer menu and add:
• “Terms and Conditions”
• “Blog”
Then save it and show that the menu is preserved correctly.
2. Create a French main menu with:
• Accueil
• L’équipe
• Basecamp Experience
• Voyages
And again, show that the menu is saved successfully and remains in French.
This would really help confirm the issue is 100% related to the WordPress.com environment — and give me something to show their support team as well.
Thank you so much for your video and for taking the time to reproduce the process — I truly appreciate your help and dedication.
It’s very helpful to see that it works correctly on your local environment, and I understand now that the issue seems to come from the hosting side.
Since the problem is being investigated by your second-tier team, I’ll wait for their feedback — but in the meantime, would you recommend that I also contact WordPress.com support to check if they might be blocking something on their side (for example, certain PHP hooks, database writes, or menu-related permissions)?
Let me know if it could help or if I should wait until your team has more information first.
Thank you again for your time and the investigation so far.
I’ve now spoken at length with the WordPress.com technical team. They confirmed they are not blocking any standard PHP hooks or database operations, but are willing to cooperate if your second-tier team can provide:
• A specific function or hook being blocked (e.g. wp_update_nav_menu_item)
• A suspected code snippet that triggers the failure
• Or any technical pointer that could help isolate the issue
Without this, they are not able to run server-level diagnostics.
Would it be possible for your team to provide even a minimal lead?
Right now, I’m completely stuck between two teams — and the site remains broken.
We’ve just confirmed through full plugin isolation and a clean theme that the issue persists. Is there any way to help us monitor what’s being blocked during the save process for nav_menu_item post types or related meta?
I wanted to thank you personally for all the time and help you’ve given me regarding the multilingual menu saving issue. Your patience, the video recordings, and your clear explanations have really been appreciated — it made a big difference on my end.
I wanted to let you know that after further investigation with WordPress.com’s technical team, the issue was resolved by manually clearing the object cache on their servers. Once they did this, the menus (both French and English) started saving properly again on my live site.
This confirms that the problem was not in WPML itself, but in how it interacted with WordPress.com’s internal object caching system — specifically affecting nav_menu_item post types and multilingual content. The bug was difficult to track because it did not always reproduce on staging, and appeared intermittently.
I’ve asked WordPress.com if there’s a way for me to manually clear this type of cache in the future, or if they could implement a more WPML-compatible cache strategy.
If you believe it’s useful, I would be happy to encourage both your technical team and WordPress.com’s to connect directly — it could help avoid similar issues for other users in the future.
Thanks again for your support and your professionalism throughout this process,
Antonio
