I am trying to: Add content at the staging environment.
Link to a page where the issue can be seen: hidden link
I expected to see: Normal admin page.
Instead, I got: This repetitive error: "This site has moved to a new location"
We have had a tour with dear Alejandro recently. He had given us some workarounds (deleting some database rows) to overcome this issue.
Question 1: Are we going to repeat this everytime we push a new version to staging?
This is frustrating.
Question 2: There has been a new warning everytime we push a staging to from production environment after latest WPML update. The warning says: "Your default language, Turkish, must be mapped to a supported language in order to use automatic translation." You can see it in the screenshot also. What does it mean? I could not see any reasonable option to go forth with this warning also.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Hello there!
This issue could be happening because of 2 reasons (and we can help you have them fixed if you tell us which situation is the one you're facing).
1) you selected the option in the banner that mentions that you are MOVING the site from one domain to another (instead of the version that mentions that the site is a COPY).
2) similar to option 1 but this time you are returning to the staging site. you had "moved" the site before so now you're stuck with this banner.
Before we proceed, can you tell us which option sounds more like your situation? because to avoid this issue in the future, i suggest that you always select the "copy" option, tht way you can move freely from one site to another, make migrations, pushes and more without this banner blocking you everytime (you will still see it but it will give you options about what to do).
If you're confused about this situation, i can try to explain it in a different way, so let me know if there's still something you don't understand and i'll do my best to help you out.
Hello (again) Alejandro and thanks for replying.
This is something like a follow up to our previous (#14192895) convo.
And the answer is 2.
Updated content and created a .wpress backup. Then recovered that backup at the production domain.
It was working flawlessly until recent WPML updates.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
You mentioned that you had applied the solution to production and staging a few times before and it had worked, but has something changed from then? maybe you deleted the staging site or maybe you didn't delete it this time instead? something even slightly different from the usual workflow that did work in the past?
Because on my end i see that at one point the production site had the "moved" option selected and the solution i gave you before applies here again.
if i recall correctly, you wanted this staging site to have the credits as well, but i don't remember if the translations made here would need to be in the production site as well in the form of translation memory, can you update me on your preference?
We usually never delete a site if we are not upgrading / changing web server environment, whether it be a production or a staging one.
As I stated before, our workflow is like this (is there any unreasonable step here?):
1. There are two identical website content at the start. Each and every byte is similar, except the URL. One of them is root domain.com, the other one is staging.domain.com.
2. There is a new content we would like to add to the website. We add the new content to staging site. Do a few arrangements (moslty for front end UI / UX adjustments).
3. If everyone is happy, start pushing the staging to production:
3.a Create a backup of staging.
3.b Copy staging backup to production.
3.c Recover that backup on production.
4. After this process we do not delete anything on any of the ends.
5. A new development cycle statrs on the *current* state of the staging.
But unfortuınately, latest WPML upgrades have successfully disrupted this process.
Answer continued: We would like to have all the translation memory, available credits and translation ability to be active on both ends. We sometimes need to fix some minor translation issues or typos etc on the production end also. Currently this use case seems not working.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Ok so the workflow hasn't changed at all from the one you had mentioned in the prevous ticket. i'd like to record myself while on the staging site, and while adding the solution i had mentioned to you before, to see if by any chance there was a difference in what you did in the previous ticket, something i might've missed or that i might've not communicated to you correctly.
I'd use a script or a plugin like adminer or phpmyadmin to access the staging database and make the changes i'd need. all while recording myself so you see every single thing i do on your staging site.
No problem Alejandro, go as you please. Plenty snapshots standing by.
You will delete those database table rows again I assume.
If this is the solution, do we need to do it again all the time? That was my main concern. Or did we break the fix at one step so that we are spending time on this ticket?
I will need your guidance also about the warning at the admin panel (the orange one at the top bar, initial screenshot has it). Is it related about this issue or a separate problem?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
I talked to our developers and it seems that the problem will indeed keep appearing and you'd have to apply the workaround i mentioned before.
We're actually working on something that will make this go away, it's almost done planning so it should be coming in the following months. for now please use the same workaround as before and i'll try to see if our developers can give me another solution to this before the final one is deployed on one of our plugin's releases
Ok, thank you.
As far as I understood, you did not apply the fix but I have to. Please confirm.
And what would you suggest about the orange warning thing at the admin bar? Is it related the same thing with the main error and workaround?
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
I didn't apply the fix, no, so you can go ahead and do it.
Quick question, though. if you are pushing the database from staging to production, it should be safe for you to just click the ""indicate that this site should be at" aaa.com"
Because in the end you'll be making all the changes in the staging site, isn't that correct? if that's the case, then while it's true you won't be able to use ATE on production, it seems like you wouldn't do it anyway because otherwise, the staging push would still overwrite those changes.
This is the "intended" solution of this workflow and it's done exactly so you don't have both sites working in parallel with ATE with the risk of losing credit or translation memory in the future.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Oh by the way the notification you mentioned: "Your default language, Turkish, must be mapped to a supported language in order to use automatic translation."
this issue happens when you have the migration banner active and it happens because while the banner is still active, it doesn't know how you want to move forward and this mapping feature requires you to have an active ATE Account which you don't have until you go through the migration procedure.
Ok, thank you Alejandro for your time and kind support.
We usually do not make changes on production. But in the past we sometimes needed a couple quick fixes. That's why, we will need both ends to be editable.
Looking forward for the fix.
Cheers to the support and development teams.
Languages: English (English )Spanish (Español )Italian (Italiano )
Timezone: Europe/Rome (GMT+02:00)
Thanks for your kind words. i've discussed with our developers about situations like this to see what solution we can have for you. an improvement is coming soon, so that's good news 🙂 all the information you provided us in this and the past tickets are really helpful in understanding the different scenarios that we need to make sure to consider in our testings.
