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.
Hi, kurze Frage dazu, was passiert wenn ich die Strings lösche für die Hauptseite ? Dann sind doch meine Übersetzungen weg oder verstehe ich das falsch?
Ich benötige ja diese Translation für meine Seite 🙂
Und wie ist das mit der Performance in anderen Sprachen ? Dort kann ich ja auch nicht einfach übersetzte Strings löschen, denn da werden sie ebenso benötigt. Denke dort ist auch der Knackpunkt der redirect.
Sollten die Probleme danach weiterhin bestehen bleiben, dann gim mir bitte Bescheid.
Ob das Problem am WPML Redirect auf das Soprachverzeichnis liegt, kannst Du dadruch testen, indem Du unter WPML > Sprachen einstellst, dass kein Verzeichnis für die Hauptpsprache verwendet werden soll.
Wenn Du aber Probleme mit Ladezeiten in Zweitsprache hast, dann wird das nicht die Ursache sein, dann dieser Redirect findet nur in der Hauptsprache der Website statt.
Hi , danke für deine schnelle Antwort. Ich werde das mit der Beta ausprobieren und mich nochmal melden.
Das mit dem redirectproblem verschwindet auf der Rootseite wenn ich das Unterverzeichnis deaktiviere. Bleibt aber für die anderen Sprachen noch. Ich werde es mit der Beta nochmal erneut testen und mich melden. Vielen Dank 🙂
Das Problem besteht darin: Wir haben ein redirect aufm Server drin, welcher von tim-vad.com/ auf tim-vad.com/de/ leitet. Ohne diesen redirect, lädt die seite schnell, jedoch springt sie nicht mehr auf /de/ wenn man die seite über die normale url tim-vad.com/ aufruft. Das müsste wpml erkennen und weiterleiten. Diese weiterleitung verursacht diese performanceprobleme. Stelle ich den redirect aus, sowie die wpml einstellung mit hauptverzeichnis ist die seite innerhalt von 1-2 sekunden geladen, jedoch ohne das benötigte /de/ verzeichnis.
Für das umschalten auf andere sprachen haben wir kein redirect. Hier dauert es ebenso lang wenn ich auf eine andere sprache umschalte. Wo hier das Problem ist, verstehe ich nicht.
Ich teste auf dem Staging aktuelle in einem minimalen Setup.
Hier findet nun bei meinem Test auf dem Staging ein Redirect von versteckter Link auf versteckter Link in 2-3 Sekunden statt.
Auch die Sprachwechsel dauern etwas 3 Sekunden.
Aktiviere ich weitere Plugins dauert es etwa 4-6 Sekunden die Seiten der Website zu laden, aber nicht mehr.
Soll bedeuten, je mehr Plugins aktiviert sind, desto länger die Ladezeit - ich gehe davon aus, dass diese, wenn alleine mit WPML und Divi Parent Theme gestetetet würde, die Ladezeit bei 1-2 Sekunden liegt, was durchaus zu erwarten und normal wäre.
Kannst Du bitte auf dem Staging sicherstellen, dass keine Weiterleitung vom Server aus stattfindet, damit ich das Problem der nicht funktionierenden Weiterleitung von der Root Page auf /de nicht wie erwartet funktioniert?
Hi, leider funktioniert das nicht, da diese Einstellung dann für staging und liveseite greift. Wenn ich dies zu testzwecken mache, kann das nur ein paar Minuten so bleiben, da sonst gewisse URLs nicht mehr erreichbar sind.
Was ich nicht verstehe, dass trotz der Aktivierten Plugins, die Seite schnell lädt sobald ich den redirect ausschalte und das Unterverzeichnis entferne.
Dann ist dort aber mein Problem, dass bei aufruf der Root-Domain nicht auf das Unterverzeichnis automatisch weitergeleitet wird, auch nicht mit dem neuen Template. Deshalb habe ich den extra redirect drin. Wie kann das gelöst werden, dass es auch ohne den redirect vom Server funktioniert ?
Ansonsten könnte ich ein Screencast schicken um die Sache zu zeigt ? Wenn ja wo könnte ich diesen nicht öffentlich hochladen?
Die lange Ladezeit auf die Du Dich hier berufst, findest also nur dann statt, wenn von versteckter Link auf versteckter Link umgeleitet wird, richtig?
Wie hoch ist diese Ladezeit genau?
Ich sehe 3 Sekunden Ladezeit beim ersten Redirect, wenn ich nur mit WP Rocket, dem Divi Parent Theme und WPML teste, aber beim erneuten Laden der Seite sind es 2 Sekunden, soll bedeuten der Redirect benötigt 1 Sekunde.
Aktiviere ich nun alle Plugins, sehe ich hier aktuell beim Redirect von der Rootpage eine Ladezeit von etwa 5.8 Sekunden.
Das ist allerdings nicht nur beim Redirect der Fall, sondern die URL versteckter Link benötigt auch beim erneuten Laden 5.3 Sekunden.
Soll bedeuten, der Redirect dauerte bei diesem Test nur 0.5 Sekunden.
Deaktiviere ich WPML lädt versteckter Link in 3.5 Sekunden, was bereits ohne WPML eigentlich recht hoch ist.
Diese 3.5 Sekunden kann Du somit von den bislang 5.3 Sekunden abziehen und folglich hat WPML einen Einfluss von 1.8 Sekunden auf die Ladezeit, wenn alle Plugins aktiv sind.
Teste ich auf dem Staging alleine mit WPML. Toolset, WP Rocket und Yoast liegt die Ladezeit bei etwa 2 Sekunden und das ebenso wenn ich von der Root Page aus weiterleite.
Deaktiviere ich nun WPML bleiebn 1.6 Sekunden Ladezeit, soll bedeuten der Einfluss durch WPML war hier eigetnlich nur etwa eine halbe Sekunde.
Ich habe dann noch die aktuellsten Versionen unserer Plugins auf dem Staging installiert, kann aber ohne WP Rocket nicht testen, weil sich das Plugin nicht deaktivieren lässt.
Was ich hier noch anbieten kann, ist zu versuchen eine lokale Kopie der Website anzulegen, um meine Test mit den Werten eines virtuellen Servers zu vergleichen und bitte dazu um etwas Geduld.
Wie bekomme ich es hin, dass auf die /de/ geleitet wird, ohne das ich einen extra redirect auf dem Server einrichten muss. Ich habe es doch als Homeverzeichnis bei WPML eingerichtet. Aber mit dem neuen Theme und dem Hook funktioniert es nicht.
Hattest Du versucht meine Empfehlungen aus meinem letzten Kommentar auf der Website anzuwenden?
Sollte die WPML Redirect Option nicht wie erwartet funktionieren, dann kann ich das auf der Website nur dann testen, wenn Du den Redirect auf dem Server entfernst oder kurzzeitig deaktivierst.
Auf meiner lokalen Kopie der Website funktioniert der Redirect wie erwartet und deshalb kann ich hier leider nicht von einem Fehler in WPML ausgehen.
Die Ursache sollte somit am Server oder den dort durchgeführten Redirects liegen.
Könntest Du dazu eventuell eine Staging Site zum Testen anlegen?
