Our 2nd-tier support team has identified a quick workaround: clone the page using the Yoast Duplicate Post plugin; the cloned page doesn't have the issue.
This may be a good workaround for now.
Our 2nd-tier team is still working on another fix for the issue, and I'll update you as soon as I receive their response.
Our 2nd-tier support team has found that it's a database issue. The workaround is to use the Yoast Duplicate Post plugin, as the duplicated posts won't have the same issue.
Please let me know if Hetsher has tried the workaround.
I understand the suggested workaround using Yoast Duplicate Post, and I appreciate the confirmation that this is indeed a database-level issue.
Before applying this workaround, I want to be careful, as this site has:
existing indexed URLs,
multiple languages,
and SEO-sensitive content.
Cloning pages would create new post IDs and URLs, which is not ideal as a structural solution and may introduce additional SEO side effects.
Given that 2nd-tier support has identified this as a database issue, I would prefer to address it at the source if possible - for example by:
cleaning or rebuilding the affected WPML translation records,
resetting locked translation jobs,
or repairing inconsistent entries in the WPML tables.
Could you please confirm whether a database-level fix or cleanup is possible on your side, now that the root cause has been identified?
If needed, I can of course test the workaround on a single non-critical page, but I’d prefer to avoid duplicating live content unless there is no alternative.
1) Please try the following on a non-critical page:
1- Edit the page in all languages and change the slug to slug-old
2- Duplicate the page in the default language
3- Change the slug from slug-old-copy to slug
4- Check the issue
2) Our 2nd-tier support was not able to find an alternative workaround, but I'll share your concerns with them.
I’ve completed the test you requested on a non-critical page. Below is a clear and final summary of the results.
Result of the test
After duplicating the page and assigning the original slug to the duplicate (test performed on the Privacy Statement page, Dutch → English):
The WPML translation editor opens normally
The translation can be saved / closed without redirects or warnings
The editor no longer falls back to the WordPress/Elementor editor
This confirms that the original blocking issue was caused by legacy database relations tied to the original post ID, not by the page content itself.
Remaining issue (important clarification)
Before these problems started, my site worked for years in local translator mode:
I only saw pencil icons
I edited translations directly myself
After saving, the icon returned to a normal pencil
Translations were never treated as “jobs” or reassigned
After the workaround:
The editor is functional again (good)
However, WPML now treats the translation as a translation job:
gear icon instead of pencil
messages such as “waiting for available translator”
in WPML → Translations, the same page appears with conflicting statuses (e.g. “needs translation” and “completed but needs update”)
This workflow behavior did not exist on my site before the issue and indicates remaining inconsistencies in WPML’s translation records.
Conclusion
The workaround successfully restores the editor and proves this is a database-level issue.
However, duplicating pages one by one is not a sustainable solution for a multilingual, SEO-sensitive site, and the original local-translator workflow has not been fully restored.
Question
Now that the root cause is confirmed, is it possible for 2nd-tier support to perform a database-level cleanup/reset of WPML translation data so the site can fully return to the original local-translator workflow (pencil icons, no translation jobs), without duplicating pages individually?
Thanks again for your help and for escalating this to 2nd-tier support.
