A client's site was developed on a staging URL, then shifted to the live site with all occurrences of the URL replaced in the site's database.
While it worked initially, some translated portions are now showing in English - in particular, those that include a URL inside a translated string.
When I go into the Translation Editor, both the 'original' and 'translation to' columns contain the staging URL, even though the live URL appears in the original post's content (and the staging URL does not appear anywhere in the database) - see screenshot.
It appears WPML is incorrectly storing the staging URL somewhere - outside of the database, perhaps in PO/MO files hardcoded on the server somewhere - and since this doesn't match the actual content, it's not finding the translation.
I've seen past forum responses where you suggest manually deleting the translation and then retranslating it. We don't want to do that as there are a large number to fix. I'm not even entirely sure how this would work, since the 'original' can't be edited and is wrong.
If WPML is storing the wrong domain for the site somewhere, can you please advise on getting these automatically replaced with the right domain?
Updating the page and reaccessing the translation editor resulted in the English versions having the right URL, but the translated versions all being blank. So they all had to be manually retranslated, which is what we were wanting to avoid.
How can the domain update be made in a better way?
This should not happen unless the editor used was changed from Classic Editor to Advanced Translation Editor.
Are you aware of such change?
Unfortunately, the only workaround would be to do the following:
1. View the page in the front end
2. Switch to the translatiton
3. click on "edit page" (not translation) & dismiss the warning
4. manually edit the URLs as you would in the default language and update.
I think you're misunderstanding the problem. Manually editing the page isn't a solution because the pages themselves do not contain the incorrect URLs. As mentioned, there are no references to the staging URL at all anywhere in the database.
The only references to the staging URL are in the Advanced Editor. All I can imagine is that you are storing the original->translation mapping somewhere hardcoded on the server (like json / mo / po) files, and those files don't get updated when a site is migrated from a staging server to a live server. That leads to the mapping for the new URL getting lost, which is why they don't automatically translate.
So the question is - where are you storing this information if not in the database, and how can you support these URLs getting automatically updated during a migration?
Yes, the ATE content is saved in a cloud server and will not be located on your site's database.
that should not cause an issue when a site is moved as many users do this quite often.
I would like to understand the workflow here better:
1. Originally did you use the Classic Editor or the Advanced Translation editor to make the translations?
Moving from the Classic Editor to ATE will cause your original translations to be lost.
The classic editor does not use a cloud server instead it uses the database.
2. Share with me a link to a page where I can see the issue now on the site.
Only the ATE. I can't share a page right now because as the translations disappeared after making the update mentioned above, we had to manually retranslate them - so they're working now, but are trying to figure out the cause.
At what point does your cloud server become aware of the change in domain and perform a search/replace on your end?
That is the Classic Translation Editor, meaning that switching to the ATE editor would remove the translation requiring you to re-do them.
"If you switch to using the Advanced Translation Editor, any content previously translated using the Classic Translation Editor will not be visible in the Advanced Translation Editor. However, they will still be visible on the site’s front-end.
You can copy and paste the existing translations from your site’s front-end or click the Translate automatically button in the Advanced Translation Editor to easily add translations."
Our ATE server recognizes the change with no problem when a site has been moved, I am not sure of the exact timing but I am positive we have no known issues with this behavior.
For example, we could create a page with an internal link -> translate it and then move the site to our cloudays staging environment you would notice that the URL will be updated.
The topic ‘[Closed] Staging site URL preventing translations, even though not in MySQL database’ is closed to new replies.
Manage Cookie Consent
We use cookies to optimize our website and services. Your consent allows us to process data such as browsing behavior. Not consenting may affect some features.
Functional
Always active
Required for our website to operate and communicate correctly.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
We use these to analyze the statistics of our site. Collected information is completely anonymous.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
These cookies track your browsing to provide ads relevant to you.
