This issue has been reported by multiple people over the past few years. Like many of those reports, we have had instances where manually translated posts inexplicably lose their translated content and get displayed with the default language's copy. This seems to happen randomly and semi-frequently (a couple pages every quarter). When it happens it only happens to one of the translated pages, not every translated page associated with the original post.
Our site's default language is English. We manually translate all of our content (i.e. we do not use WPML's advanced or classic translation editor) and we have this setting enabled for all site content, not just specific posts.
When we create content we:
1) Make a new post in the default language, English
2) Duplicate this post to whatever language(s) we want to manually translate
3) Edit the post for the language we want to enter translations for and click the "Translate independently" button
4) Enter in all translated copy then publish.
Things are usually fine and the translated pages are displayed as expected. However, like many other WPML users, sometimes a translated page will no longer display translated content and instead, the English content appears.
Looking through a lot of the old support tickets relating to this issue, I found these to be the most common recommendations, all of which we have implemented on our site over the years:
1) The WPML Translation Editor is disabled on our pages/posts.
2) The Advanced Custom Fields Multilingual plugin is disabled/not installed.
3) ACF Field Groups are set to "Not translatable" in WPML > Settings > Post Type Translation.
4) We've deleted all non-English ACF Field Groups so only the English ACF Field Groups exist.
5) Our WP Memory Limit is set to 256M
6) PHP max input variables is set to 10000
The most recent page that reverted to English is this Chinese page: hidden link. I've attached some screenshots showing the WPML language panel for the original English version of this page as well as the Chinese one.
This problem can happen due to many reasons, but, since you are translating by yourself primarily on your own site, I can't be sure what is causing this.
However, you can go through some standard debugging procedures like:
IMPORTANT: Take full backup of your website and database beforehand. It is highly advised to try the following on a staging/dev site first, so your live website isn't compromised.
- Enable debugging on your site. See https://wpml.org/documentation/support/debugging-wpml/ for details.
- Deactivate all plugins except WPML and its addons and check for the issue.
- Check with a standard WordPress theme like 2021 or 2022.
- If issue isn't reproducible at this point, continue to activate other plugins one by one while rechecking for the issue.
- and finally retry by switching to your theme.
I understand this issue may not be easy to reproduce like you mentioned it does not happen very often. But at this moment I suspect there may be a conflicting event causing this to break or corrupt. Because all plugins and themes use the WordPress' shared ecosystem, these are highly likely to conflict with each other.
I appreciate your reply, but your suggestions aren't feasible. Considering that this phenomenon occurs once every month or so, we cannot disable all of our plugins (except WPML) and switch to a WordPress core theme for that length of time. It's disappointing that so many people have reported this issue to your team over the years and there isn't a more clear explanation of why it happens and what can be done to rectify the issue. I understand that WordPress is a highly extensible ecosystem that is shared among the theme and all the activated plugins making it difficult to pinpoint what is the cause in each individual's case, but can't you and your team narrow down the possible whys and what sort of things MIGHT lead to behavior like this?
My apologies for the disappointment but as a matter of fact, there can be several reasons. WPML has been improving to fix such issues, reported over the time.
We need to check for the current reason. If the issue only happens with WPML with a default WordPress theme, then of course we would have solid reasons.
But everyone uses different types of plugins and themes, so it is quite logical to debug issue accordingly and find out the actual reason.
I understand that the issue doesn't happen so often and a production site can't be down for that amount of time.
Is this possible for to you create a staging site at this point, based on the production site? And provide the URLs to the pages which you recently (or previously) have identified with the problem.
So we can then work on the staging site without risking the production one. And can try to reproduce the problem and check the database for any anomalies.
I've set your next reply as private, in case if you want to provide a staging site for debugging.
IMPORTANT: If you don't see the section for providing access information, do not write in the message box or the information may appear as public.
I 've started working on it and 'll try my best to reproduce the issue by trying different things and 'll get back to you ASAP with my findings (today).
I did some tests with WPML and WPML String Translation active only. I created a couple of new posts and a page. For the page I copied the content from the page you had mentioned with the problem.
Then I duplicated these, turned to Translate Independently, translated to Chinese (zh-hans) and published.
I then edited these in default as well as Chinese translation, trying to make these different and hoping to affect any of these in the process. But so far there's nothing I could reproduce as an issue.
To continue further, I 've 2 suspects here:
1) Those custom blocks which you mentioned.
2) The ACF field groups, you mentioned in first message.
Can you activate only the relevant plugins to these 2? And provide some instructions on using these? So I can then retry to reproduce the issue.
Thank you for the update and your efforts to recreate/diagnose the issue. I've gone ahead and activated ACF Pro and our custom plugin (Hello Tools) which has all of our custom blocks. They have a custom block category called "Hello Blocks" which should be the first group when you open the block inserter. They should be pretty self-explanatory.
I tried a couple of test pages and found some unusual behavior:
A) The "Default Template" has a predefined "Introductory text" block, which I can't remove. I can't also publish the page using this template. There's an error "Publishing failed. Invalid parameter(s): template" (see attached).
Is this part of your Hello plugin or coming from ACF Field Groups?
B) I was able to publish page using "Blog (alternative)" and "Blank" templates. But as soon as I published the page, the page seemed to have translations in all languages (see attached).
While automatic translation is turned off. Is this also due that Hello plugin? Because if I deactivate this plugin, I can publish with default template, as well as, I can see + icon and duplicate option for all the languages. Means I can apply the workflow you mentioned earlier, for example:
- Create a page and publish.
- Duplicate it for another language.
- Switch to language and "Translate Independently".
- Update the content and publish.
So I am suspecting the issue you mentioned in the beginning, has something to do with your custom coding (plugin and/or theme).
I disabled some of the code that was leading to those behaviors that you noticed. For issue (A), we had some javascript code that was inserting that custom "Introductory text" block for every new page. For issue (B), we have code hooked into the 'wp_insert_post' action to run 'wpml_admin_make_post_duplicates' when a new post is published for the first time so that we have it duplicated in every language without having to manually do that step. I disabled that action from firing.
I'll try once again but with & without your custom plugin, and, 'll see if I can reproduce the issue.
But so far what I can assess is that the custom coding can be a problem in this case. Like you already know that everything in WP ecosystem shares the same codebase, it really is complex to find out what's causing the certain problem.
As of the scope of this forum, we do not provide support for custom coding. All we can check if this is really coming from WPML, or, from a compatible plugin (https://wpml.org/plugin/).
Anyways, I'll check once again and 'll try to reproduce the issue and 'll update you today accordingly.
I tried again as I mentioned previously. I even tried in reverse order, like creating a page in Chinese first and then duplicating to English (default) language. Then further making changes in both.
This seems to work fine so far with and without "Hello Tools" plugin.
So I think, as you mentioned, the issue doesn't happen very often. I can suggest the followings at this point:
- Keep the staging site available. And whenever that issue happens again, refresh the staging site with a copy of the production one, before fixing the content in the production site. So you'll have an exact moment of the problem.
- Perhaps review your custom code for any chance which may run into this problem or a particular scenario may create this problem.
And of course report again accordingly (either in this ticket if it hasn't been closed or in a new ticket).
If you would want someone more experienced with WPML vs Custom Coding, you can contact a WPML Contractors at https://wpml.org/contractors/.
I appreciate your time and efforts looking into this issue and I definitely understand the challenge of determining an exact cause given the open-source, extensible nature of the WordPress environment. It would be nice to know if there is anything you and your team can think of that would be things to look out for in our custom code or other plugins that might lead to this kind of behavior in which a fully translated post reverts back to the default language, but still is considered to be a translation (i.e. it is not a duplicate of the default language, it's still a manual translation according to the WPML plugin). Conceptually, theoretically, what/why/how can this kind of thing happen? What would trigger it? Are there WPML functions that do that perform a similar function that our theme/plugins inadvertently triggered or mimicked? You all know your code and functionality best, so I'd hope that you can at least come up with some theories on what could be causing such a thing to occur especially given the fact that this has been reported so many times over the years.
