Yesterday we moved the site from development to production. It's the same site, hosted in the same place, we simply pointed an A record for the domain to the new server and updated the site URL. When we logged back in (with the live/production URL), we got the prompt asking if we had moved the site or if we wanted to keep the other URL. We indicated this is the final URL and got a "you're all set" (or something to that effect).
But now we're getting this persistent "This site has moved to a new location" warning and we can't use translation management. The weird thing is that the warning says the site was moved to the correct (live) URL, and then it says that "translations you do on hidden link (live URL) will not appear on this site." "This site" IS the correct, live URL. At the bottom it asks us if we want to indicate that the site should be at hidden link (development URL), which makes no sense. It's as if that development URL value got stuck somewhere in the configuration.
If it helps in any way, this new site replaces an old site where we also used WPML (the old site was from 2013). While in development we were using a new key (for the development URL), but now we're using the same (old) key because the live URL is the same.
The site is working fine on the front end (translated content and strings display correctly), but we're unable to use translation management, and the warning is making our client anxious.
Languages: English (English )Portuguese (Brazil) (Português )
Timezone: America/Sao_Paulo (GMT-03:00)
Hi there,
Thanks for your contact.
Before your ticket is assigned to one of my colleagues, please allow me to walk you through some initial debugging steps. This will help speed up the support process.
The errata documentation he shared will most likely resolve this error for you, however, it would be great if you could assist our team in understanding what might have caused this behavior to trigger.
I understand you are moving from a dev to a production environment.
- Which hosting service are you currently using?
- Do you use a standard process to deploy WordPress, for example you are not deploying through GIT
- Is there a specific reason you would have added the following declarations in your wp-config.php
Mateus, I looked at the errata but WP_HOME and WP_SITEURL are not set dynamically on my wp-config.php, so I can't really use this workaround. In fact, I hardcoded both values to florida-allergy.com in wp-config.php.
Bobby:
- Which hosting service are you currently using?
GoDaddy (these servers were migrated from MediaTemple when GoDaddy acquired them)
- Do you use a standard process to deploy WordPress, for example you are not deploying through GIT
Yes, standard (through Plesk)
- Is there a specific reason you would have added the following declarations in your wp-config.php
I didn't add those declarations, they're not on my wp-config.php (see response to Mateus above)
If you did not add the declarations would you mind asking your hosting provider why these declarations were added?
Same response as above, they're not on wp-config.php (I know the errata alludes to this, but that's not the case for me)
I found another support article that mentions something about a potential conflict in certain DB values in the wp_options table (Ilyes mentions it here: https://wpml.org/forums/topic/this-site-has-moved-to-a-new-location-4/#post-14167515). I looked at the values he mentions in a backup I made of the DB, and both the live URL and the previous development URL appear in "otgs_wpml_tm_ate_cloned_site_lock". I can provide the values in a secure message, if you enable it...
There should not be a need to hardcode those values in wp-config.php by the way.
Regarding the values my colleague in the other thread has mentioned these are expected to exist in the database. The values allow us to verify that they match what we have on our side.
I have enabled the private reply field where you can share them and you can also share access to the backend for me to take a further look if needed.
But anyway, without including any private information, I was able to fix the issue.
I can't provide WP or FTP access because this is a healthcare client (so my client won't allow this kind of access). I was able to fix the issue on my own, by changing the development URL to the live URL for the following DB entry:
otgs_wpml_tm_ate_cloned_site_lock
(before I made the change, this DB entry had both the live URL and the dev URL; I changed the dev URL to the live URL - so now it has the live URL twice - and the problem went away)
I don't know why this problem happened in the first place, but I'd suggest that you guys look into a way to offering a more automated fix that doesn't require manually changing DB values (some users might not have the skill or nerve to do it, and it's risky).
The way I see it, if one has a WPML license, and a license key activated for the website URL where the plugin is running, that should suffice (as it does with 99% of commercial plugins). For other plugins (including some I'm running on this site), when the site went live, the licenses I was using got deactivated (because the URL no longer match the license), and all I needed to do was generate a new license key for the live URL, update it in the back-end, and I was good to go. This whole "migrating from dev to production" situation is weird and confusing.
