[Warten auf die Bestätigung des Benutzers] Der Query-Loop block wird nicht korrekt überseetzt
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.
Hintergrund des Themas:
Ich versuche, den Query Loop Block in WPML korrekt zu übersetzen. Wir verwenden den Block mit den Einstellungen Versatz, Limit und Filter - Übergeordnete. Der Filter für die übergeordneten Seiten wird nicht korrekt übersetzt. Ich habe bereits die Lösung unter https://wpml.org/de/forums/topic/block-query-not-translating/ ohne Erfolg ausprobiert. Den Fehler hatten wir schon vor Ewigkeiten gemeldet. Scheinbar besteht er weiterhin. Einen Link zu einer fehlerhaften Seite kann ich nicht anbieten. unsere Redakteure fixen den Fehler asap, da wir Traffic auf die Seiten bekommen.
Die Symptome:
Der Filterwert wird nicht korrekt auf die Übersetzungen angewendet, was zu einer leeren Ergebnisliste im Frontend in allen Übersetzungen führt. Wenn die originale Version der Seite bearbeitet wird, geht die manuell korrigierte Query-Loop-Filter-Einstellung verloren, und alle Übersetzungen müssen erneut manuell korrigiert werden.
Fragen:
Ist der Fehler mit dem Query Loop Block und den Filtereinstellungen in WPML immer noch nicht gelöst?
Warum geht die manuell korrigierte Query-Loop-Filter-Einstellung verloren, wenn die originale Seite bearbeitet wird? (Selbst, wenn der query loop block nicht bearbeitet wird, sondern nur ein anderer Text geändert wird.)
ich habe dir auf der Testseite einen Demo-Inhalt erstellt und diesen mit dem ATE übersetzt.
Die Seite habe ich vorab auf DE als Hauptsprache gestellt, weil wir da sbei uns live auch so haben.
zudme habe ichc mit einem Plugin Demo-Conten timportieert.
Dort tritt der gleiche Fehler auf, den wir auch live bei uns im Shop haben.
- DE: versteckter Link (Original)
- EN: versteckter Link (fehlerhafte Übersetzung, Frontend kein query loop output zu sehen)
bitte zeige mir einen Link auf der Testseite, auf der es funktioniert.
Wenn ich es mir anschaue, scheint es nicht zu funktionieren.
Zudem ist es das gleiche XML-Snippet, von dem ich im Eingangspost bereits berichtet habe, dass es live bei uns nicht funktioniert.
Aber das von mir aus separat.
Erstmal sollte eure Testseite funktionieren, bevor wir live etwas versuchen.
Die props sind so auch auf den übersetzten Seiten sichtbar.
Jedoch wird Frontend bei allen Übersetzungen nur folgendes HTML ausgegeben:
<div class="wp-block-query --redacted is-layout-flow wp-block-query-is-layout-flow">
<div class="wp-block-query-no-results">
<p>Error when retrieving the list.</p>
</div>
</div>
Hast du eine Idee, wie wir das effizient debuggen können?
Normalerweise müssten wir nun eine staging erstellen, WPML erneut verbinden und nacheinander Plugins deaktivieren, um vielleicht den Übeltäter zu finden, vielleicht auch nicht.
Das kostet uns locker eine Stunde, vermutlich mehr.
Kannst du uns verraten, wie ihr die Ausgabe vom query loop block modifiziert - welche php filter werden genutzt? Ich kann schauen, ob andere Plugins eventuell den selben Filter nutzen und dort eine Nebenwirkung wahrscheinlich ist. Das sollte für uns deutlich schneller gehen, um ggf. einen Fehler auf den ersten Blick zu erkennen.
Wenn nicht, dann machen wir es über eine separate Staging. Dauert dann halt ein bisschen.
Kann man das Problem mit den gleichen Einstellungen auf meiner Test-Site replizieren?
Sind alle Unterseiten auf der Website übersetzt und veröffentlicht?
Wurde der Block nach dem Anlegen der Config editiert und der originale Inhalt erneut gespeichert, bevor er erneut übersetzt wurde?
---
Ich kann gerne anbieten, mir das einmal genauer anzusehen und beim Testen behilflich zu sein.
Ich möchte einen temporären Zugriff (wp-admin und FTP) auf die Website anfordern, um das Problem genauer zu untersuchen.
Die dafür erforderlichen Felder findest du unterhalb des Kommentarbereichs, wenn du dich anmeldest, um die nächste Antwort zu hinterlassen. Die Informationen, die Du angibst, sind privat, was bedeutet, dass nur Du und ich sie sehen und darauf zugreifen können.
WICHTIG
Lege bitte unbedingt eine Sicherungskopie der Website und der Datenbank an, bevor Du uns den Zugriff gewährst.
Wenn Du die Felder "wp-admin / FTP" nicht sehen kannst, werden deine Anmeldedaten für Post und Website als "PUBLIC" (Öffentlich) festgelegt. Veröffentliche die Daten NICHT, es sei denn, du siehst die erforderlichen wp-admin / FTP-Felder.
Ich muss hier ggfls. Ein Plugin namens "All In One WP Migration" installieren, um eine Kopie der Website anzulegen, auf die ich das Problem genauer untersuchen kann.
Ich wäre allerdings auch sehr dankbar, wenn Du zu diesem Zweck selbst eine Staging Site, bzw. Kopie der Website von deinem Server aus bereitstellen könntest.
Bei Fragen zum Erstellen einer solchen Staging Site kannst du deinen Hosting-Anbieter konsultieren. Achte bitte darauf, dass WPML auf diesem Staging ebenso unter https://wpml.org/de/account/websites/ registriert sein muss.
Solltest du dazu nicht in der Lage sein, eine solche Kopie der Website zum Testen bereitzustellen, dann lass es mich bitte auf diesem Ticket wissen.
Das private Antwortformular sieht folgendermaßen aus: versteckter Link
Klicke beim nächsten Mal auf "I still need assistance".
Video: versteckter Link
Beachte bitte, dass wir verpflichtet sind, diese Informationen auf jedem Ticket individuell anzufordern. Wir dürfen nicht auf Zugangsinformationen zugreifen, die nicht speziell auf diesem Ticket im privaten Antwortformular übermittelt wurden.
Die Config muss in diesem Fall angewendet werden, es ist nur möglicherweise so, dass wir in diesem Fall keine Standard-Config bereitstellen, weil der Block je nach Einstellung eine gesonderte Config benötigt. Ich kann jedenfalls bestätigen, dass der Query Block in der aktuellen wpml-config.xml-Datei von WPML nicht berücksichtigt wird.
Ich werde dazu das Second-Tier-Support-Team konsultieren.
Auf dem Staging kann ich aktuell bestätigen, dass es wie erwartet funktioniert. Um festzustellen, warum es auf der Live-Site nicht funktioniert, müsste ich einen Blick auf diese Website werfen und ggfls. eine Kopie zum Testen anlegen.
Sollte das möglich sein, dann erteile mir bitte Zugriff zur Live-Site. Ich werde dort nur einen Blick ins Backend werfen und dann ggfls. das Plugin "All in One WP Migration" installieren, um eine lokale Kopie zum Testen anzulegen.
Auf deiner Beispielseite war aktuell kein Filter im Block gesetzt.
Der Wert für "Offseet" war im Block auf 40 gesetzt, was dazu führt, dass keine Ergebnisse angezeigt werden, wenn weniger als 40 Unterseiten existieren.
Auf der Website war unter WPML > Einstellungen > Benutzerdefinierte XML-Konfigurierung keine Custom Config für den Block angelegt.
Die Config muss aktuell angewendet werden. Danach muss die Übersetzung des Blocks aktualisiert werden. Die funktioniert bei meinem Test wie erwartet.
Beispiel: versteckter Link
Übersetzung: versteckter Link
Lass mich bitte wissen, solltest du dazu noch Fragen haben.
danke für deine Bemühung.
Leider hilft das nicht weiter.
Ich habe dir, wie im Ticket davor geschrieben, extra eine neue Testseite mit der Live-Website-Config erstellt.
Dementsprechend auch ohne den zusätzlich wpml-config Eintrag.
Ich schreibe in meinem Ticket, dass das Problem gelöst wird, wenn man alle Plugins deaktiviert (auch wpml & woo), die wpml-config anpasst, und dann alles neu aktiviert.
Das können / möchten wir live ungern so machen.
Die frage war also, ob es einen anderen weg gibt.
Da ich emails bekomme, wenn ein Plugin erneut aktiviert wird, habe ich gesehen, dass du nicht den Live-Zustand der Website getestet, sondern Plugins reaktiviert hast.
Dass das den Fehler löst, habe ich oben schon beschrieben.
Ist nur live nicht wirklich praktikabel, einfach mal alle Automatisierungen und den kompletten Shop abzuschalten, nur weil wpml einen core wordpress block nicht übersetzt.
wenn ich auf einer live- ode Testseite von uns nur die wpml-config aktualisiere ohne Plugins zu deaktivieren und neu zu aktivieren, dann hat der neue config Eintrag keinen Effekt und der Übersetzungsfehler bleibt bestehen. Das ist gerade das eigentliche Problem, das mit der neuen Testseite eigentlich untersucht / gelöst werden sollte.
Gibt es eventuell einen besseren Weg?
Falls dir keiner einfällt: Ich kann dir auch gerne noch ein letztes mal eine neue Testseite erstellen. Dann muss es jedoch korrekt getestet und gelöst werden. Das kostet jedes mal gut Zeit, eine Testseite zu erstellen und komplett zu konfigurieren.
Das Ziel ist es, den Fehler zu lösen ohne alle Plugins zu deaktivieren.
Nur so kommen wir live ohne größere Aufwände und Störungen zu einem anwendbaren Ergebnis.
Es muss alleine die Custom XML Config in den Einstellungen von WPML eingefügt werden.
Das geschieht unter WPML > Einstellungen auf dem Reiter "Benutzerdefinierte XML-Konfiguration“.
Danach editiert man den originalen Inhalt, speichert den Inhalt erneut ab und aktualisiert dann die Übersetzung.
Ich habe zudem vor ein paar Tagen einen Feature Request mit einer möglichen Lösung intern weitergeleitet, wie man in Zukunft das Aktualisieren der originalen Inhalte nach dem Einfügen einer neuen benutzerdefinierten XML-Konfiguration umgehen kann. Ich warte darauf, auf Antwort unseres Produktmanagers und des Entwicklungsteams.
ich habe oben doch beschrieben, dass ein einfaches Anpassen der WPML-Config bei uns nicht hilft.
Da ändert sich Frontend nichts.
Als ob die Änderung der config nicht bei WPML im System ankommt.
Auf der bereitgestellten Testseite klappt es, weil dort von dir alle Plugins mal deaktiviert und neu aktiviert wurden.
Es ist wie ein Bug / Glitch.
Wie soll ich den Fix nun live bekommen, ohne dort alles zu deaktivieren?
Wie gesagt: Ich kann dir gerne noch eine Testseite erstellen. Du kannst dort einfach die wpml config aktualisieren ohne Plugins zu deaktivieren und wirst sehen, dass es keinen Einfluss hat.
Ich habe das schon auf mehreren Testseiten und auch live probiert. Es passiert einfach nichts.
Wenn man einmal alles deaktiviert hat, dann flutscht die wpml config wieder. Aber das kann nicht zu erwarten sein, dass wir so auf der Live-Seite vorgehen.
Ich kann mir das gerne einmal auf einer Test Site (Staging) anschauen.
Ich möchte einen temporären Zugriff (wp-admin und FTP) auf die Website anfordern, um das Problem genauer zu untersuchen.
Die dafür erforderlichen Felder findst Du unterhalb des Kommentarbereichs, wenn Du dich anmelden, um die nächste Antwort zu hinterlassen. Die Informationen, die Du angibst sind privat, was bedeutet, dass nur Du und ich sie sehen und darauf zugreifen können.
WICHTIG
Lege bitte unbedingt eine Sicherungskopie der Website und der Datenbank an, bevor Du uns den Zugriff gewährst.
Wenn Du die Felder "wp-admin / FTP" nicht sehen kannst, werden Ihre Anmeldedaten für Post und Website als "PUBLIC" (Öffentlich) festgelegt. Veröffentliche die Daten NICHT, es sei denn, Du siehst die erforderlichen wp-admin / FTP-Felder.
Das private Antwortformular sieht folgendermaßen aus: versteckter Link
Klicke beim nächsten Antworten auf "I still need assistance".
Video: versteckter Link
Beachte bitte, dass wir verpflichtet sind, diese Informationen auf jedem Ticket individuell anzufordern. Wir dürfen nicht auf Zugangsinformationen zugreifen, die nicht speziell auf diesem Ticket im privaten Antwortformular übermittelt wurden.
In dem Fall scheint das manuelle Setzen der Optionen des Query Blocks in den Zweitsprachen direkt beim Editieren der Seite im WordPress Editor eine Lösung darzustellen.
Siehe: versteckter Link
Ich habe die Seite erneut übersetzt und die Einstellungen bleiben danach gespeichert.
