Hello and thank you for your feedback, I'll try to answer you and provide what I can to make the resolution of this ticket faster.
1. You can download the plugins from your download page https://wpml.org/account/downloads/ and share them using DropBox or GDrive. Here a folder where they can download them hidden link
If you are always redirected to your current website, I suspect that redirection is cached in the browser, please clear the cache or try with a different browser.
3. We(WPML Support team) won't be able to contact the JetPack team, but if we reproduced the issue in our servers and confirmed it is a compatibility bug, our compatibility team will work on it and if they need help from JetPack, they will contact them, in fact, they have contacted them before.
Good idea with the plugins, I'll upload them.
The hosts file is edited under localhost name resolution is handled within DMS itself. I've tried the clone on two browsers after clearing history. The attached shows as far as I can go on the clone installation. All product links from this page redirect to the live site.
To work around I've disabled jetpack and added several other plugins to replace most functions. They sem to work without issues.
I got this from jetpack-
Looking into this issue one of the things I noticed is you are using the WPML feature allowing you to have different domains for languages. For example:
hidden link
hidden link
Can you ask the WPML support if they used multiple domains as well and see if this reproduces under a single domain? We think it's important to identify whether this is a factor or not.
They are also requesting access to a test site. Would it be possible for them to use yours?
As you can see in the attached image(hard-coded-urls.png), the product links are hardcoded to your website, the secondary domain that I have added is working.
You can access a translated product with one of these ways:
- By URL, change the domain in the URL of the translated product on your website.
- By entering the original product, then using the language switcher, check the attached image(langauge-switcher-urls.png)
I do agree with JetPack, maybe this issue is only happening when using languages in domains, that's why I set up the migrated site with multiple domains.
WPML can use another URL format than domains, you can change the language format to use URL param or languages in folders in WPML->Languages, please test it on your website or in the migrated site if you(you or JetPack support) can reproduce the issue on it. https://wpml.org/documentation/getting-started-guide/language-setup/#language-url-format
Regarding the test server, of course, JetPack can use the migrated site, just give them a user/password(users are the same as your website) or login in and create a user for them.
Great, I was able to access a translated product through the language switcher. I'm a bit confused though. You say you haven't been able to replicate the error on your server, but just to clarify, have you tested the site for this error when set up with a language per domain? Showing the issue cannot be replicated on a different setup is not very helpful if we don't also know that it can't be replicated with an identical setup.
Changing to languages in folders sounds like it could have major ramifications, so I'm not going to rush into that.
Of course, after you migrated your website I configured another "fake" domain for Spanish "es.wordpress-219772-1101634.cloudwaysapps.com".
Why I called it "fake", because it does not exist and will not resolve to an IP address, but if you add it to your local hosts file it will resolve and this way, it will work.
So, on our servers with languages in domains the issue did not appear, I just tested again with languages in folders(maybe this is not needed), the issue did not appear.
Let me know what JetPack support will find after your tests.
Heard from Jetpack earlier. They are saying they are unable to replicate the error on the clone site but note that Jetpack is not connected. I connected Jetpack on the live site and attempted to do likewise on the clone but was unable to do so.
I also noticed that the PHP is out of date on the clone.
I can ask our system admins to upgrade PHP in the migrated site, but I am afraid this issue will be hard to reproduce, and if we can't reproduce it we won't be able to investigate it and fix it.
I will suggest doing the following:
- Create a staging site on your platform.
- Migrate your website on it and keep all plugins activated.
- If the issue is not reproduced in your staging site, migrate it back to the primary server, this will probably resolve the issue.
