[Résolu] Incorrect URLs in secondary language, German, after migrating to other subdomain

[Auteur]

Publications

[simonM-5]

Hi Support

We are facing an urgent issue with incorrect URLs in our secondary language, German, after migration of our site from one subdomain to another, which is preventing us from taking our site live to production.

For example, if we migrate from dev.native-nanny.de to test.native-nanny.de not all German URLs are updating correctly. This has the effect that in the migrated site, some German URLs are still pointing to the same item in dev.native-nanny.de instead of test.native-nanny.de. Our default language URLs in English appear to be working correctly.

However I would like confirmation from Toolset and/or WPML that the problem does not lie elsewhere. For example, in the migrated site, in WPML String Translation, if I search for "dev.native-nanny.de" and check the "Include translations" box, no instance of the string is found, however certain German URLs still point to dev.native-nanny.de/.....

I also tried searching the migrated database using MySQLAdmin Search functionality for the string "dev.native-nanny.de". The only instances turn up in the WooCommerce store in the wp_options table, as expected, since our WC store is currently registered there.

I have prepared the following pdf with screenshots to show the problem more clearly. (Please delete the URL from the ticket after noting it, thanks!)

lien caché

I would like to know
1) where the migrated environment is retrieving these faulty URLs from, although the correct URLs are available on the migrated site and work fine if entered manually. From a Toolset Content Template? Toolset View?
2) Why the string "dev.native-nanny.de" isn't turning up in the WPML String Translation database search, even though somehow the migrated site is managing to show them

- Providing debug info from our dev subdomain.
- The Admin access I'm granting you will work on both dev and test subdomains. Simply replace dev with test in any relevant URLs.
- If you require FTP access to test subdomain, please let me know.
- If you need a Duplicator Package, please feel free to create one, but please let me know once the files have been downloaded so I can delete them from our server as this poses a security risk.

FYI I have opened a ticket in parallel with SnapCreek, the authors of Duplicator Pro, to eliminate the possibility that their Search and Replace functionality is the culprit, still waiting on their answer.

Kind regards
Simon

[Waqar]

Hi Simon,

Thank you for contacting us and I'd be happy to assist.

During troubleshooting, on your 'test' website, I noticed that the Duplicator package had properly replaced the base URLs in the database, but they need to be updated in the 'MO' file that WPML maintains for those string translations.

For example, for the first 3 incorrect links from your PDF file, I went to string translation (WP Admin -> WPML -> String Translation) and filtered by their string domains ( 'toolset-views-1254' domain for the link to go to the outbox, 'toolset-views-1256' domain for the link to go to the inbox, 'toolset-content-templates-1252' domain for the Download Nanny Interview Questionnaire link ).

As soon as, I updated the respective string's translation in German (even with a small change), the correct link started showing on the front-end.

You can go to WP Admin -> WPML -> Support and click the blue 'Troubleshooting' link and click the 'Show custom MO Files Pre-generation dialog box' which should regenerate MO files and you won't have to update each string translation entry manually.

In case, you still see some old entries coming from the string translations, it would be best to start a new ticket at the WPML support forum, to get the most accurate and up-to-date information about this feature.

regards,
Waqar

[simonM-5]

Hi Waqar

Thanks so much, you're a genius! At first glance, the results look really promising. This is great! 😃😃

It concurs with what Duplicator Pro support just got back to me with a few hours back (appending their response below):

In light of what we are seeing here, does that mean that I should regenerate the files directly before doing a duplication or immediately after duplication on the target environment (in this case "test")?

Thanks and kind regards
Simon

===============
I think I finally figured out where the wrong URLs are but I can't give you a solution because Duplicator doesn't work on files, let alone binary files.

---
Binary file page-builder-shortcode-strings-2113-de_DE.mo match
Binary file page-builder-shortcode-strings-14341-de_DE.mo match
Binary file elementor-2091-de_DE.mo match
Binary file elementor-2101-de_DE.mo match
Binary file page-builder-shortcode-strings-8536-de_DE.mo match
Binary file elementor-286-de_DE.mo match
Binary file page-builder-shortcode-strings-1940-de_DE.mo match
Binary file page-builder-shortcode-strings-966-de_DE.mo match
Binary file toolset-views-1256-de_DE.mo match
Binary file elementor-2113-de_DE.mo match
Binary file page-builder-shortcode-strings-91-de_DE.mo match
Binary file elementor-16632-de_DE.mo match
Binary file elementor-7843-de_DE.mo match
Binary file page-builder-shortcode-strings-407-de_DE.mo match
Binary file elementor-7840-de_DE.mo match
Binary file elementor-91-de_DE.mo match
Binary file page-builder-shortcode-strings-2101-de_DE.mo match
Binary file toolset-views-1254-de_DE.mo match
Binary file toolset-content-templates-1252-de_DE.mo match
Binary file page-builder-shortcode-strings-859-de_DE.mo match
Binary file page-builder-shortcode-strings-3321-de_DE.mo match
Binary file toolset-forms-1250-de_DE.mo match
Binary file elementor-1229-de_DE.mo match
Binary file elementor-966-de_DE.mo match
Binary file page-builder-shortcode-strings-16632-de_DE.mo match
Binary file page-builder-shortcode-strings-7505-de_DE.mo match
Binary file elementor-1427-de_DE.mo match
Binary file toolset-forms-1242-de_DE.mo match
Binary file page-builder-shortcode-strings-408-de_DE.mo match
Binary file toolset-content-templates-859-de_DE.mo match
Binary file toolset-forms-16794-de_DE.mo match
Binary file elementor-407-de_DE.mo match
Binary file page-builder-shortcode-strings-1772-de_DE.mo match
Binary file gutenberg-14684-de_DE.mo match
Binary file toolset-forms-16624-de_DE.mo match
Binary file elementor-337-de_DE.mo match
Binary file page-builder-shortcode-strings-7843-de_DE.mo match
Binary file elementor-1940-de_DE.mo match
Binary file page-builder-shortcode-strings-2091-de_DE.mo match
Binary file elementor-10387-de_DE.mo match
Binary file page-builder-shortcode-strings-7840-de_DE.mo match
Binary file elementor-1231-de_DE.mo match
Binary file elementor-2094-de_DE.mo match
Binary file toolset-forms-1308-de_DE.mo match
Binary file page-builder-shortcode-strings-3312-de_DE.mo match
Binary file toolset-forms-1251-de_DE.mo match
Binary file toolset-forms-929-de_DE.mo match
Binary file elementor-10385-de_DE.mo match
Binary file elementor-1772-de_DE.mo match
Binary file toolset-forms-921-de_DE.mo match
---

In folder wp-content/languages/wpml these translation files contain the wrong URL.

I hope this can help you solve the problem.
Please when you have figured out what action to take to update the translation files let us know, we may add a section in the documentation for users who have this problem.

In theory the translation strings should be text not URLs, we have never had this problem before.
===============

[Waqar]

Thank you for your kind words and I'm glad I could help.

You'll need to regenerate the MO files on the new/target environment after the migration has been completed.

[simonM-5]

My issue is resolved now. Thank you!