[Geschlossen] Übernahme von Layoutänderungen bei Aktualisierung der englischen Seite
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.
vielen Dank für deine Hinweise und deine Unterstützung.
Ich habe die vorgeschlagenen Schritte getestet, leider ohne Erfolg. Zudem ist der Ansatz insgesamt sehr komplex in der Umsetzung. Ich arbeite als Webdesignerin und benötige hier eine Lösung, die im Alltag zuverlässig und ohne technischen Umweg funktioniert – genau das sollte WPML ja eigentlich leisten.
Für mich ist es aktuell keine Option, langfristig ein unvollständiges oder inkonsistentes Ergebnis auf der Website darzustellen.
Deshalb bin ich vorerst wieder auf den Classic Editor zurückgegangen. Damit funktionieren zumindest Teile der englischen Inhalte wie gewünscht, und die restlichen Elemente setze ich nun manuell um.
Ich gehe davon aus, dass WPML kontinuierlich weiterentwickelt wird – dieses Thema wäre aus meiner Sicht definitiv ein relevanter Punkt. Zumal WPML auch von Qode als empfohlene Lösung eingesetzt wird. Ich habe das Thema parallel auch beim Qode Support adressiert.
Unabhängig davon, wo die Ursache liegt, wäre es sinnvoll, wenn hier eine stabile Lösung entsteht – ob gemeinsam oder auf Tool-Seite.
Dir auf jeden Fall vielen Dank für deinen Einsatz und deine Unterstützung.
Der Fehler tritt hier im Grunde bereits auf dem originalen Inhalt auf.
Wie du auf dem originalen Inhalt im WordPress-Editor sehen kannst, werden die Inhalte, bei denen Inline-CSS in einem Text-Widget verwendet wird, bereits im WordPress-Editor nicht korrekt dargestellt.
Das legt sich, wenn man zum Beispiel ein Raw-HTML-Widget verwendet.
Deshalb bitte ich darum, zu testen, ob sich das Problem löst, wenn man auf dem originalen Inhalt die betroffenen Text-Widgets durch Raw-HTML-Widgets ersetzt.
Es handelt sich hier zudem um einen Grenzfall. Inline-CSS sollte nur in bestimmten Ausnahmefällen angewendet werden. Ich hatte dazu bereits erwähnt, wie man das mit einer einfachen CSS-Regel in WordPress über den Customizer lösen kann.
Solltest du Hilfe bei der Anpassung benötigen, kann ich diese gerne für dich durchführen.
vielen Dank für deine Anregung, die ich mir gerne merke.
Ich habe aber jetzt bereits auf den Classic Editor umgestellt.
Und vielleicht ein wertvoller Impuls für dich:
bei der Aktualisierung der englischen Inhalte werden dabei zumindest die kleinen blauen Buttons, das Calendly und einige andere Dinge korrekt übernommen.
Manuell habe ich dann ein paar Buttontexte, wie der ganz oben sowie die Links eingetragen.
Das zeigt aus meiner Sicht, dass hier auch ein Problem beim Advanced Editor liegt, wenn der Classic zumindest die grundsätzlichen Layouts entsprechend von der deutschen Seite übernehmen kann, während der Advanced Editor das nicht tut.
Ich weiß nicht, welche Erkenntnisse daraus zu ziehen sind. Aber ich denke, hier sollte WPML schon in der Software geprüft werden.
Vielen Dank für deine Unterstützung und wertvollen Gedanken.
Die Ursache für die Probleme liegt durchaus im Advanced Translation Editor (ATE), aber noch viel eher in der Art, wie WPBakery mit Inline‑CSS in Text‑Widgets umgeht.
Warum Inline‑CSS problematisch ist:
Backend‑Darstellung: WPBakery serialisiert die Inhalte seiner Widgets. Inline‑CSS kann diese Struktur stören, weshalb die Widgets im Backend nicht mehr sichtbar sind, obwohl sie im Frontend korrekt angezeigt werden.
Übersetzungsprobleme: Der ATE erwartet saubere Textfelder. Inline‑CSS innerhalb von Text‑Widgets verwirrt den Parser, sodass Übersetzungen nicht übernommen werden. Mit dem Classic Translation Editor (CTE) funktioniert es, weil dieser weniger strikt ist und das komplette HTML ausgibt, aber das ist kein Fehler im ATE, sondern im Grunde zu erwarten. Der ATE wurde zur reinen Text-Übersetzung und vor allem für die automatische Übersetzung erstellt.
Wartbarkeit: Inline‑CSS erschwert spätere Anpassungen, Migrationen und Übersetzungen. Saubere Trennung von Inhalt und Gestaltung ist hier die Best Practice.
Warum das Raw‑HTML‑Widget die richtige Lösung ist
Das Raw‑HTML‑Widget gibt den Code direkt aus, ohne dass WPBakery ihn serialisiert. Inline‑CSS wird dort korrekt verarbeitet, ohne dass Widgets verschwinden.
Wenn Inline‑CSS unbedingt notwendig ist, gehört es in ein Raw‑HTML‑Widget, nicht in ein Text‑Widget.
Fazit
Dies ist kein Fehler im ATE, sondern ein Randfall durch die falsche Verwendung von Inline‑CSS in WPBakery Text‑Widgets. Eine Eskalation an die ATE‑Entwickler ist daher nicht sinnvoll. Die nachhaltige Lösung besteht darin, Inline‑CSS zu vermeiden oder – falls unvermeidbar – das Raw‑HTML‑Widget zu nutzen.
