[Waiting for user confirmation] Different domains

You mentioned a few pages as examples on this ticket.

https://wpml.org/forums/topic/different-domains-2/page/2/#post-16331128

I do not recall which one of those pages I tested, but I was able to confirm the issue.

I then merged all existing organisations of your site on our system which merged all the translation memory for all registrations of the site.

After that I opened the WPML Translation Editor on the example content again, and the issue was solved.

It is unclear to me why the site is getting registered over and over and why there are so many organisations for the site on our system.

The issue has been escalated to teh second tier support team. A colleague will get in contact with you as soon as possible, but please take note that this will be not earlier than tomorrow.

---

Also take note, that staging site and production site are different from registering a site as development site or production site on wpml.org.

On wpml.org each site URL needs a proper site key. Means, one key for your staging, one key for the production site. Surely, you could create a dev key for the staging so that visitors will see the banner, which is what you did.

A dev site will have a banner letting the visitors know that the site is not in production yet. You can then set the page later to production mode and the banner disappears.

The site key in this case could remain the same, if a dev site and production site would use the same site URL.

If theses sites would not use the same site URL, which is your case, then they will need to be registered the site again after changing from dev to production, as also the site URL would change.

The change from dev to production on wpml.org would usually only be necessary if the site URL remains the same.

If the site URL changes after migration, the new site has a new site key.

Each site needs its own key. This means if you move from staging to production, usually you need to go to wpml.org and again copy and paste the correct site key into WordPress, as you might have copied the staging's site key to the production site.

Further, both sites should alwasys stay registered with the same site key.

When moving from staging to production you will further always see the migration banner. This is expected and you should always use the "Yes, this is only a copy" option if you move from a staging to a production site and both sites are still used.

In the second option of the migration banner you should always use to share credits between both sites.

Take note, that if the sites are connected in Translation Management, then this banner should not longer appear.

You should not unregister the sites and register them again.

Most important, both sites need to be connected in Translation Management, which is what we did on this ticket.

It did not work right away to connect the site, as the many migrations created maybe 30+ organisation on our translation system. After all I made sure now that all those organisations are merged.

The site URLs for those organisations are:
hidden link
hidden link

I have merged all those organisations and usually you should not longer see a migration banner when moving the site and not have issue with translation memory.

Now, it might be that there is still an issue, as you said the site used a different site URL earlier. It might be that there are more organisations in our system that use translation memory for your site.

This is why I escalated to the second tier support for a further revision.

---

Also, take note that I found a organisation for hidden link which had 60.000 credits assigned.

Is it correct, that you are not longer using this site URL? If so, let me know and I will move those credits to hidden link.

---

Further, if you are still having issue with lost translation segments, then please provide me exact examples. I need to know on which page this issue occurs to be able to help you.

Right, in this case you would move the dev site to prodcution and the dev site disappears. I suppose the system would then automatically assign the site key to the new URL.

This is not how it works if you have a staging and a production site only at the same time. In this case each site needs its proper site key adn the site key should never be changed.

---

Can we please focus on the issue with lost translation segments, as this ticket is becoming way to enhanced.

Please provide me the title of a page on which I can currently still recreate the issue.

At this point I do sadly not know what the translation memory is not working as epxected.

Usually, as those pages have been translated already on the staging site, the translations should be auto-completed on the production site.

I would suggest we wait for now for the Second Tier Support to have a look into this.

If you feel the second option is the one for you then perfect we can use that one 🙂 remember that you will have an option to choose on every migration so the important thing is to know when it would be worth to choose one or the other.

------------------

About your replies:

1) You ask which button. I take it you mean the one I mention on minute 2:33 of the video. The button I mean is not shown on the video but if you choose the option "no" (i changed the address...) and then in the future reuse the same staging site you migrated from (which I know you mentioned you usually don't do), you'll get another migration banner that just says that you have already "moved" the site to another domain and that if you want to return and use the translation editor on that staging site again, you'd be able to do so by clicking a button or a Link in that migration banner.

That's the button i meant.

2) Ok, let me know what is it still not clear about this procedure so I can explain it to you 🙂

3) You mention

if I want to make huge changes, I will create a new staging site...

Ok, but is there any scenario where you will make translations on the live site while a staging site is created an being used? if the answer is yes, have you had staging sites that you just discard instead of migrating them to the live site?

Because in the case you do just discard the staging site afterwards, the "first" option (yes - this is only a copy) is probably going to be of use to you

4) Sure, I'll await for another page. What I can tell you is that as my colleague said resaving the permalinks when you changed from subdirectories to domains is important.

At the same time if you add the links in a relative way (/my-site-page as opposed of hidden link) would also make it so the domains would not be changed automatically because they are not seen as a "real" link. I don't think this is your case, but just so you know 🙂

3) I'll make it easier to know when to select either option:

- If you will discard the staging: select the First option (Yes- This is only a copy...)

- If you will end up migrating the staging back to the live site, select the second option (No - I changed the address...)

I think that's the easiest way to understand when to select one over another 🙂

4) It's not after a migration but when you switch URL Formats from something like "site.com/fr" to "siteinfrench.com". if you're not doing that in the migrations, then you don't need to save the permalinks, otherwise, resave them after the migration 🙂

-------------------------

Once all this part/topic is understood and could be considered closed, is there something else that has a high priority that you'd wish me to help you with? Which one so we can move onto that new topic? (I'd probably separate the ticket to make things easier and clearer down the road).

Regards.