Dieses Thema ist gelöst. Hier finden Sie eine Beschreibung des Problems und der Lösung.
Problem: Der Kunde berichtet, dass eine Meldung dargestellt wird, welche auf unterschiedliche URLs hinweist, obwohl diese auf dieselbe IP-Adresse zeigen.
Lösung:
Wenn das Backend der Website nur unter einer spezifischen Domain läuft und das Frontend je nach Anfrage eine andere Domain hat, kann der Kunde die folgenden Regeln in der wp-config.php beibehalten:
/* make it work with proxy */
if (isset($_SERVER['HTTP_X_FORWARDED_HOST'])) {
$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
}
/* assure subpath */
define('WP_SITEURL', 'https://***.de-fra1.cloudjiffy.net/shop');
define('WP_HOME', 'https://' . $_SERVER['HTTP_HOST'] . '/shop');
Die Website-URL ist dann statisch und die Front-End-URL dynamisch.
Dies ist das technische Support-Forum für WPML – das mehrsprachige WordPress-Plugin.
Mitlesen können alle, doch nur WPML-Kunden können hier Fragen veröffentlichen. Das WPML-Team antwortet im Forum an 6 Tagen pro Woche, 22 Stunden am Tag.
Ich frage mich auch, warum auf den anderen Sites die Haken nicht angezeigt werden
Dies passiert entweder, wenn die Meldung zu unsern Servern blockiert ist (durch WebAuth, Security Einstellungen etc.) oder wenn dies beim WPML Setup nicht angehakt wird. Dies beeinträchtigt jedoch die Funktion nicht, der WPML Site-Key ist bereits korrekt registriert (Dieser Key ist die Registrierung der Lizenz), die Haken dienen rein Ihrer Information.
Zu Ihrer zweiten Nachricht:
Und was für einen Sinn macht solch eine Meldung eigentlich? Die URL sind doch alle gleich in der Meldung!!
Wenn diese Installation nun unter ask-***.eu/shop läuft, können Sie in der Meldung "No" wählen, dann wird diese URL für das Translation Memory und die Permalinks verwendet. Die Option "Yes" wird nur benötigt, wenn Sie die Hauptseite auf z.B. eine Staging/Testumgebung migrieren, dann setzt das System diese URL als Kopie und legt neue Keys zur Authentifizierung zu unseren Servern an, die Authentifizierung der Haupt-URL bleibt jedoch bestehen.
Dies erlaubt mehrere Staging / Produktionsinstanzen aufzusetzen, welche das Translation Memory teilen.
Sorry, da hatte ich den falschen Screenshot erwischt. Manchmal stehen da tatsächlich die gleichen URL.
Zur Info: ask-dad.eu und dad-prd-shop.de-fra1.cloudjiffy.net zeigen per DNS beide auf die gleiche IP. Sie führen also beide zur gleichen Umgebung, unserer PRODUKTION.
Gut, aber wie konnekten wir denn jetzt wieder die Umgebungen?
Ich brauche zunächst mal einen Connect für dad-p01-shop.de-fra1.cloudjiffy.net (das ist einer unserer Staging Umgebungen). Und wenn dort alles funktioniert, brauche ich den Konnekt für dad-prd-shop.de-fra1.cloudjiffy.net und/oder ask-dad.eu
Zur Info: ask-dad.eu und dad-prd-shop.de-fra1.cloudjiffy.net zeigen per DNS beide auf die gleiche IP. Sie führen also beide zur gleichen Umgebung, unserer PRODUKTION.
Das macht keinen Unterschied, die WP Home/Site-URL ist nicht identisch, daher wird die Seite als verändert erkannt und per Meldung gefragt, ob es eine Migration gab bzw. ob es nur eine Kopie ist.
Ich brauche zunächst mal einen Connect für dad-p01-shop.de-fra1.cloudjiffy.net (das ist einer unserer Staging Umgebungen). Und wenn dort alles funktioniert, brauche ich den Konnekt für dad-prd-shop.de-fra1.cloudjiffy.net und/oder ask-dad.eu. Können Sie das einrichten?
Das ist nichts, was wir über unseren technischen Support einrichten können, SIe müssen dies direkt im Backend durchführen.
1) Sie müssen auf der Hauptdomain nur mit "Nein" bestätigen, dass die Seite nicht migriert wurde, und dies die "Haupt-URL" ist.
2) Alle anderen Instanzen können mit "Ja" als Kopie bestätigt werden. Zum "connecten" gibt es da nichts, wie gesagt, dies betrifft nicht die WPML Lizenz.
Aktuell bekomme ich den Migrationsbanner nicht mehr.
Und was ist meine Hauptdomain, wenn mehrere Domains auf die gleiche Instanz zeigen? Ich hatte das bereits alles mal gemacht und sogar Shared Usage der Credits eingerichtet zwischen mehreren Instanzen, aber jetzt ist alles wieder weg.
Was muss ich tun, wenn ich den Migrationsschirm nicht habe??
Da steht bei uns nichts, weil wir mehrere domains haben. wir nutzen den forward host, der uns von unserem reverse proxy gegeben wird. aber das ist jetzt auch egal.
In der Vergangenheit habe ich immer ein Ticket aufgemacht, und der Supporter hat dann irgendwas gemacht und die Connection war wieder da.
Wenn das nicht geht, muss ich wissen was ich mache. Nehmen wir für den Moment an, es gibt genau eine Instanz (dad-p01-shop.de-fra1.cloudjiffy.net), da bin ich eingeloggt und WPLML zeigt mir bei Tools nur an, dass ich keine Credits habe. Was mache ich jetzt?
Ja, genau. das hatte ich gemacht. ich hatte die Seiten, die registriert sind alle für die gemeinsame credit nutzung verbunden. Jetzt hat keine Seite mehr credits...
Danke für die Info. Wir prüfen dies. Ich möchte jetzt nicht einfach nur die Site-Domain migrieren, da es ansonsten vermutlich demnächst wieder passiert, wenn eine URL Änderung erkannt wird. Ich prüfe dies mit unserem Team, um eine dauerhafte Lösung zu finden.
Zur Info: ask-dad.eu und dad-prd-shop.de-fra1.cloudjiffy.net zeigen per DNS beide auf die gleiche IP. Sie führen also beide zur gleichen Umgebung, unserer PRODUKTION.
Sie können die beiden Domains nicht für den Zugriff auf das Dashboard verwenden, auch wenn sie auf dieselbe IP-Adresse verweisen. WP Dashboard läuft nur unter dem DB-Wert "siteurl", daher müssen Sie eine dynamische URL-Deklaration in wp-config.php haben. Können Sie dies bestätigen?
Falls ja, können Sie uns bitte den exakten Code nennen, wie die Site und Home-URL in der wp-config.php definiert wurden? Bei einer normalen Konstante wäre die Eingabe zumindest im Backend ersichtlich, auch wenn ausgegraut/gesperrt.
Sollte wirklich eine dynamische URL-Deklaration definiert sein, wäre dies ein erwartetes Verhalten und wir werden prüfen, wie sich dies am besten lösen lässt.
Hi Marcel,
danke für Deine Fragen. Das scheint mir in die richtige Richtung zu gehen.
Also: Wir lassen WordPress in einem Container laufen bei einem PaaS Anbieter.
Das bedeutet, dass wir Admins und Entwickler über eine CJ-Domain auf die Container zugreifen (dad-prd-shop.de-fra1.cloudjiffy.net).
Alle User kommen über eine domain, die per DNS so konfiguriert ist, dass sie zunächst mal dort landen, was wir "pages" nennen. Das sind statische Webseiten, die etwas zum Produkt erklären.
Von pages aus werden sie weitergeleitet. Pages agiert als reverse proxy.
Und damit verwenden wir in WordPress immer den Forward Host, den pages uns liefert. Kommt der User also von ask-dad.de, nutzt Worpress diese URL; kommt der user von frag-dad.de, dann nutzt WP diese...
Deswegen steht in der wp-config.php:
/* make it work with proxy */
if (isset($_SERVER['HTTP_X_FORWARDED_HOST'])) {
$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
}
Das DNS ist so konfiguriert, dass Subdomains wie d01.frag-dad.de auf Staging-Umgebungen landen (jeweils das pages Modul einer Staging Landschaft) und alle Hauptdomains auf der Produktion.
Ich habe unsere Architekturübersicht angehängt. Oft sagen Bilder ja mehr als meine tausend Wörter... 😉
Das bedeutet, dass wir Admins und Entwickler über eine CJ-Domain auf die Container zugreifen (dad-prd-shop.de-fra1.cloudjiffy.net).
Das heißt, das Backend der Website läuft nur unter dad-prd-shop.de-fra1.cloudjiffy.net
und das Frontend hat je nach Anfrage eine andere Domain. In diesem Fall können sie die Regeln wie folgt beibehalten:
/* make it work with proxy */
if (isset($_SERVER['HTTP_X_FORWARDED_HOST'])) {
$_SERVER['HTTP_HOST'] = $_SERVER['HTTP_X_FORWARDED_HOST'];
}
/* assure subpath */
define('WP_SITEURL', '<em><u>versteckter Link</u></em>');
define('WP_HOME', '<em><u>versteckter Link</u></em>' . $_SERVER['HTTP_HOST'] . '/shop');
Die Website-URL ist dann statisch und die Front-End-URL dynamisch.
