[Geschlossen] Kritisches Problem: Übersetzungs-Job erzeugt Endlosschleife und tausende Datenbankeinträge bei Fat...
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.
wir sind scheinbar auf ein sehr kritisches Problem in der Funktionsweise von WPML gestoßen, das zu einer Endlosschleife in der Übersetzungs-Warteschlange führte und unsere Datenbank mit tausenden fehlerhaften Einträgen gefüllt hat.
Problembeschreibung:
In der Sitemap unserer Website (erstellt von Yoast SEO) erschienen plötzlich tausende Duplikate einer bestimmten Seite für 2 unserer 5 Sprachen. Die Anzahl dieser fehlerhaften Einträge wuchs minütlich, was uns zur sofortigen Analyse zwang.
(Während der Analyse haben wir festgestellt, dass in der Vergangenheit auch andere Unterseiten betroffen waren, und dort auch tausende Einträge in der DB existierten.)
Analyse und Ablauf des Problems:
Ausgangssituation: Wir haben vor Kurzem zwei neue Sprachen zu unserer Website mit WPML hinzugefügt und die automatische Übersetzung (via DeepL) für ältere Inhalte angestoßen.
Der Auslöser: Eine der zu übersetzenden Seiten enthielt einen veralteten Shortcode von einem Drittanbieter-Plugin (German Market). Dieser Shortcode war nicht mehr in Gebrauch und die zugehörige Funktion im Plugin war deaktiviert. Dieser Shortcode erzeugte einen fatalen PHP-Fehler, wenn man versuchte, die Seite zu speichern oder eben zu übersetzen.
Verhalten von WPML: Anstatt den Übersetzungs-Job für diese eine Seite mit einer Fehlermeldung abzubrechen, scheint WPML in eine Endlosschleife geraten zu sein:
WPML hat versucht, die Seite zu übersetzen.
Dabei wurde der fatale PHP-Fehler durch den Shortcode ausgelöst.
Der Übersetzungs-Job ist daraufhin "steckengeblieben" (stuck).
Anstatt den Vorgang zu stoppen, hat WPML die Seite sofort wieder neu in die Übersetzungsschlange gestellt.
Dieser Vorgang wiederholte sich unendlich oft. Bei jedem Versuch wurde ein neuer Beitrag in der <code>wp_posts</code>-Tabelle angelegt. Diese Einträge waren jedoch unvollständig: Außer einem <code>post_meta</code>-Eintrag für <code>wpml_word_count</code> wurden keine weiteren Metadaten gespeichert. Die resultierenden Seiten erzeugten beim direkten Aufruf einen 404-Fehler.
Die Folge: Unsere <code>wp_posts</code>-Tabelle wurde mit tausenden sinnlosen Einträgen überflutet, was wiederum die Sitemap von Yoast unbrauchbar machte.
Fehlermeldung aus den Server-Logs:
Der auslösende Fehler war folgender:
<pre><code>PHP Fatal error: Uncaught Error: Call to a member function get() on null in .../wp-content/plugins/woocommerce/includes/wc-notice-functions.php:82
Stack trace:
#0 .../wp-content/themes/wordpress-theme-atomion/woocommerce-german-market/second-checkout2.php(48): wc_add_notice('<p>Deine Bestel...', 'error')
#1 .../wp-content/plugins/woocommerce-german-market/inc/WGM_Template.php(154): include('/data/sites/web...')
#2 .../wp-content/plugins/woocommerce-german-market/inc/WGM_Shortcodes.php(413): WGM_Template::load_template('second-checkout...')
#3 .../wp-includes/shortcodes.php(434): WGM_Shortcodes::add_shortcode_check(Array, '', 'woocommerce_de_...')
</code></pre>
Unsere Lösung:
Wir konnten das Problem beheben, indem wir den fehlerhaften Shortcode manuell aus dem <code>post_content</code> der Originalseite entfernt haben. Danach konnten die Übersetzungs-Jobs korrekt abgeschlossen werden und die Schleife war beendet. Wir haben die Datenbank anschließend bereinigt.
Unsere Schlussfolgerung und Bitte an WPML:
Auch wenn der ursprüngliche Fehler durch einen Shortcode eines Drittanbieter-Plugins ausgelöst wurde, liegt das Kernproblem unserer Meinung nach im Fehler-Handling von WPML.
Eine Software wie WPML sollte in der Lage sein, einen fatalen Fehler, der während eines Übersetzungsprozesses auftritt, abzufangen. Anstatt in eine ressourcenfressende Endlosschleife zu geraten, die die Datenbank zumüllt, sollte der betreffende Job gestoppt und als "fehlgeschlagen" mit einer entsprechenden Fehlermeldung im Log markiert werden.
Wir bitten die Entwickler, das Fehler-Handling des WPML Translation Managers zu überprüfen und robuster zu gestalten, damit solche externen Fehler nicht das gesamte System lahmlegen können.
Das ein Job hängen bleibt, wenn ein Fehler vorliegt, ist leider zu erwarten. Der Job sollten in dem Fall unter WPML > Übersetzungsmanagement > Jobs abgebrochen werden.
Ich verstehe richtig, dass dieser originalen Inhalt dann unerwarteterweise dupliziert wurde und da hier automatisch im Hintergrund übersetz wird WPML für jedes Duplikat eine neue Übersetzung angelegt hat?
Sollte das "automatische Übersetzungen im Hintergrund" nicht aktiviert gewesen sein, dann ist es sehr unwahrscheinlich, das WPML damit beginnen würde automatische Übersetzungen zu erstellen.
Ist diese Option jedoch altiviert, dann wäre das zu erwarten, dass WPML immer dann eine Übersetzung erstellt, wenn ein originaler Inhalt aktualisiert oder erstellt wurde.
Die Frage ist, was das Duplizieren des originalen Inhaltes ausgelöst ist und das könnte ggfls. nicht durch WPML entstanden sein.
Bitte nenne mir die URL (Permalink) der originalen Seite, damit ich mir das einmal im System anschauen kann.
Da das Problem aktuell nicht mehr vorzuliegen scheint, kann ich an dem Punkt nur anbieten mit das einmal genauer anzuschauen, solltet ihr eine Staging Site bereitstellen können, auf der man das Problem weiterhin sehen kann.
bin mir nicht sicher, ob ich das Problem korrekt rüberbringen konnte.
Hier ein konkretes Beispiel für euch zum Reproduzieren:
1. ich lege eine Unterseite mit einem Shortcode an, der funktioniert. (/test/; Original DE, Übersetzungen FR, EN)
2. ich speichere die Seite, wpml übersetzt sie mit "translate everything automatically" via deepL in alle sprachen (FR, EN)
3. Irgendwann kommt ein Theme oder Plugin-Update und der Shortcode schmeißt nun seit dem Update einen fatalen Fehler, den wir nicht mitbekommen haben
4. Wir möchten expandieren und fügen in WPML neue Sprachen hinzu (IT, ES)
5. WPML versucht, die Unterseite /test/ mit dem fehlerhaften Shortcode automatisch in die neuen Sprachen zu übersetzen (IT, ES)
6. auto translation schlägt fehl, in der DB werden nun im Minutentakt neue Einträge für die zwei neuen Sprachen / Übersetzungen der Unterseite hinzugefügt. Es gibt also für die IT / ES-Versionen irgendwann tausende korrupte Einträge in der DB.
7. Da Yoast SEO die Sitemap aus der DB-Tabelle wp_posts generiert, wird diese komplett vollgemüllt.
Der Originalbeitrag wird nicht dupliziert, sondern die Übersetzungen, die noch nicht erfolgreich angelegt werden konnten, werden wie in einer Art infinite loop immer und immer wieder neu in die DB inserted.
Der Fehler hört erst auf, wenn man den Originalinhalt von dem fehlerhaften Shortcode befreit und neu speichert.
Wenn du mit diesem konkreten Beispiel das Ticket ganz oben noch einmal neu liest, könnte es ggf. besser zu verstehen sein.
Habe es oben eher allgemein gehalten, vllt. war das zu allgemein.
Eine Staging zum reproduzieren haben wir nicht. Wir können eine erstellen, jedoch würde das noch mehr Zeit kosten und dieser Fehler hat uns bereits über 10 Stunden in der Analyse & Behebung gekostet.
Wir würden uns freuen, wenn ihr das Thema intern testet, wir haben uns größtmögliche Mühe bei der Erstellung des Tickets gegeben, damit der Fehler im Idealfall reproduziert werden kann.
danke für deine ehrliche Rückmeldung bzgl. dem Problem des Eskalierens auf die nächste Ebene.
Bin mir nicht sicher, ob die Tragweite des Fehlers rübergekommen ist.
Wir haben knapp 10 Stunden in Analyse, Fehlerbehebung und temporäres Monitoring investiert, weil WPML uns die Datenbank vollgemüllt hat.
Das kostet Zeit und Geld.
(Siehe ersten Post: "Außer einem post_meta-Eintrag für wpml_word_count wurden keine weiteren Metadaten gespeichert." Es sieht sehr sehr stark nach einem Fehler in einer WPML-Transaktion aus. Normalerweise müssten zig andere Metawerte existieren, sie sind jedoch nicht vorhanden.)
Ich kann verstehen, dass es für WPML schwierig oder auch nervig ist, sich um die Fehler anderer Plugins zu kümmern.
Gleichzeitig denke ich, dass ein solides error handling die Basis einer professionellen Software ist.
WPML sollte damit umgehen können, dass es ggf. im post_content einen fatalen Fehler gibt.
Natürlich sollte solch ein Fehler im Idealfall gar nicht erst entstehen und eine Behebung der Ursache durch den wirklichen Verursacher ist angebracht.
Da bin ich voll bei dir.
Gleichzeitig können solche Fehler bei einem erweiterbaren System wie WordPress natürlich einfach mal passieren.
Bis wir den Fehler mitbekommen, den Verursacher des Fehlers kontaktiert und einen Fix erhalten haben, ist die Datenbank bereits vollgemüllt.
Wwie gesagt: Es kamen bei uns fast minütlich neue, korrupte Einträge in wp_posts hinzu.
Abwarten ist also viel zu spät.
Dann ist das Kind schon in den Brunnen gefallen und es entsteht großer Zusatzaufwand.
Wir wären sehr erfreut, wenn ihr das oben beschriebene Szenario zumindest einmal intern durchtestet.
Falls ihr den Fehler reproduzieren könnt, freuen wir uns über ein verbessertes Error Handling in WPML.
Wir stehen bei Fragen gerne zur Verfügung.
---
Kann mir vorstellen, dass es aufwändig sein könnte, dieses Thema im Detail anzugehen.
Vllt. könnte ein einfacher Weg erstmal sein:
- Jeder Job, der einen fatalen Fehler hat, und nicht abgeschlossen werden kann, wird nicht in der DB gespeichert statt, wie aktuell als korrupter Eintrag. Der Inhalt wird nicht erneut in die queue gepackt und bleibt unübersetzt.
- Eine nicht übersetzte Seite ist meiner Meinung nach weniger schlimm als tausende korrupte DB-Einträge, die niemand mitbekommt und minütlich mehr werden, weil WPML es ständig neu probiert und es immer wieder fehlschlägt, wenn man translate everything automatically aktiviert hat.
Ich habe ehrlich gesagt Zweifel, dass der Second-Tier Support oder unsere Entwickler Verantwortung dazu übernehmen würden, wenn ein Fehler durch den Shortcode des Drittplugins entsteht.
Aufräumarbeiten an der Datenbank sind ebenfalls nicht über den Support abgedeckt.
Ich stelle jedoch gern eine WPML Test Site bereit, auf der Du versuchen kannst das Problem zu replizieren, damit ich mir das einmalgenauer anschaue.
Du müsstest dazu das German Market Plugin bereitstellen, das für den Shortcode verantwortlich ist und es sollte sich um die Version handeln, mit man das Problem replizieren könnte.
Ich verstehe richtig, dass das Problem in der aktuellen Version des Plugin bereits behoben wurde? Hast Du noch Zugriff zur alten Version?
Um welchen Shortcode von German Market und welche Version des Plugins handelt es sich hier?
lass uns gerne auf einer Testseite versuchen, den Fehler zu reproduzieren.
Wir brauchen dazu eine fertig eingerichtete Seite mit translate everything automatically mit deepL + auto Veröffentlichung der übersetzten Inhalte.
Vllt. habt ihr eine Vorlage, die ihr installieren könnt, damit wir nicht alles manuell einrichten müssen.
Unser Setup war:
- WPML (mit string translation, media translation, seo add on, etc.)
- WCML
- WooCommerce
- Yoast SEO
- ein Legacy Theme (kein full site editing / block theme)
- Inhalte verwalten mit Gutenberg
- Original-Sprache: DE
- Fremdsprachen aktiv: EN, FR
- serverseitige Cronjobs alle 5 Minuten
Zum testen würde ich einfach ein custom plugin installieren, das einen Shortcode mitbringt und dann versuchen wir, den Fehler zu reproduzieren.
Wir können aber auch das code snippets plugin nehmen, falls ich nichts installieren soll.
Ich bin mir an dem Punkt nicht sicher, was hier von Seitens WPML erwartet wird.
Zur Test Site:
Wenn absichtlich ein Fehlerhafter Shortcode implementiert wird und das zu Problemen in WPML oder anderen Plugins führt, dann muss der Auslöser (hier Shortcode) korrigiert werden.
Auf der Test Site kann ich leider keinen Server-Zugriff ermöglichen. Sollten hier absichtlich Fehler produziert werden und die Website zusammenbrechen, werde ich sie nicht wieder herstellen können.
Zu German Market:
Wenn das Problem aktuell auf der Website nicht mehr auftritt, weil Das German Market Plugin korrigiert wurde, dann ist im Grunde schon alles erledigt.
Wäre das früher an uns gemeldet worden und wir hätten festgestellt, dass das Problem an einem Shortcode von German Market liegt, dann hätten wir das ebenso an German Market weitergeleitet.
Ich bin mir an dem Punkt nicht sicher, was hier von Seitens WPML erwartet wird.
Als WPML Nutzer erwarte ich, dass WPML einen translation job abbricht und nach x Neu-Versuchen storniert wird, wenn es beim Anlegen einer Übersetzung zu Problemen kommt.
Stattdessen wurde der Übersetzungsprozess für einen Inhalt unendlich oft und gefühlt minütlich neu gestartet und hat die Datenbank mit korrupten Einträgen vollgemüllt und die Sitemap ist in der Größe explodiert.
Das habe ich mehrfach versucht zu erklären.
Eventuell sprechen wir aneinander vorbei.
Es scheint so, als würde es so rüberkommen, dass ich WPML dazu auffordere, anderer Leute Fehler zu beheben. Das ist nicht mein Ziel.
WPML sollte jedoch damit umgehen können, dass unerwünschte Fehler im post_content auftreten können und einen Übersetzungsversuch ggf. abbrechen statt komplett frei zu drehen, wie es bei uns passiert ist.
Es wäre in diesem speziellen Fall eher zu erkraften, dass eine Übersetzung einer Seite nicht aktualisiert / angelegt wird, als dass die Datenbank vollgemüllt wird. Nur darum geht es mir.
Mir fällt keine andere / bessere Erklärung ein.
Habe nicht den Eindruck, dass wir hier weiterkommen.
Eventuell müssen wir uns in diesem Fall darauf einigen, dass wir uns nicht einigen können.
Das wäre durchaus ärgerlich, weil solch ein Fehler sehr viel Nacharbeit für Seitenbetrieber auslöst.
Sicher, ich verstehe das, aber wenn eingestellt ist, das alles automatisch übersetzt werden soll und ein Drittplugin verursacht, dass bestehende Inhalte dupliziert werden, dann wird WPML nur seine Job tun und neu erstellte Inhalt wie erwartet übersetzen.
Sind die Jobs abgeschlossen wird WPML nicht weiter tun, es sein denn der originalen Inhalt wird aktualisiert.
Deshalb geht es eher darum, was die Ursache des Fehlers war, der zu den duplizierten Seiten geführt hatte. Verstehe ich richtig, dass die Ursache hier am Shortcode von German Market lag?
Beachte bitte auch, dass der Advanced Translation Editor durchaus Jobs abbricht, wenn er einen Fehler feststellen kann. Diese Fehler findet man unter WPML > Support > ATE Error Log.
German Market hat keine neuen Seiten erstellt.
Der Shortcode hatte einfach nur eine dynamische Ausgabe von Bestelldaten.
Es gab einfach einen Fehler im Shortcode-Code, der einen fatalen Fehler in der Frontend-Ausgabe erzeugt hat.
Niemand hat neue Seiten in der Originalsprache hinzugefügt, die WPML triggern sollten.
Die damals in der DB gefundenen, korrupten wp_posts-Einträge deuteten eher darauf hin, dass WPML die Übersetzungen tausendfach neu angelegt hat - siehe Erklärungen ganz oben.
Originalinhalte waren nicht betroffen.
Ich werde intern Rücksprache halten und dir bis Ende der Woche Rückmeldung geben, ob wir hier weiter dran bleiben oder uns von diesem Ticket zurückziehen.
Wir haben mittlerweile weit über 15 Stunden in das Thema gesteckt, liefern umfangreiche technische Informationen für eure Entwickler und ein Fortschritt in der Lösungsfindung scheint nicht absehbar.
Bei der Problemstellung und dem Ausmaß an Aufwand, den eine Behebung für uns als WPML-Benutzer verursacht, habe ich eher erwartet, dass zügig probiert wird, den Fehler zu reproduzieren, ggf. auch direkt von euren Entwicklern.
Es ist leider für uns unmöglich zu wissen, wie der Fehler aufgetreten ist ohne einen Blick auf die betroffene Website geworfen und ein Debugging durchgeführt zu haben.
Wir können ein solches Problem leider nur dann intern weiterleiten, wenn wir eine Kopie einer Website haben, auf dem man das Problem sehen kann oder wenn sich das Problem auf einer Sandbox replizieren lässt.
Solltet ihr eine Staging Site haben, auf der man das Problem aktuell sehen und reproduzieren kann, dann schaue ich mir das gerne mal an.
wir ziehen in Erwägung, eine Testseite zu erstellen, um euch das Problem zu zeigen, falls es reproduzierbar ist.
Wir melden uns die Tage dazu noch einmal.
Um die Testseite sinnvoll zu erstellen, muss jedoch WPML auto translate wieder verfügbar sein.
Wir hatten die letzten zwei Tage kaum Zugriff auf den Deinst, siehe das andere Ticket von uns: https://wpml.org/de/forums/topic/ist-die-ate-wpml-api-immernoch-down/
Habe heute noch nicht geschaut, ob es wieder klappt.
Erst ab dann können wir dir eine Testseite erstellen.
Das Thema '[Geschlossen] Kritisches Problem: Übersetzungs-Job erzeugt Endlosschleife und tausende Datenbankeinträge bei Fat…' ist für neue Antworten geschlossen.
