meine Produktbeschreibungen sind lange Tabellen, die in jeder Sprache in den Zeilen gleich sind, nur der Header / Tabellenbeschriftung ist in allen Sprachen unterschiedlich. Ich habe das daher wie folgt bisher gelöst:
Header als Anfang einer Tabelle in custom field des jeweiligen (sprachenspezifischen) Channels abgelegt:
table thead tr td /td … td /td /tr /thead
Produktbeschreibung wurde nur einmal in Default Language angelegt, wird dann ja in alle Sprachen übernommen. Produktbeschreibung hatte dann Rest der Tabelle:
tbody tr td /td … td /td /tr /tbody /table
Im Template habe ich dann beides hintereinander ausgegeben und es hat eine prima Tabelle gemacht und super schön angezeigt.
Jetzt geht das nicht mehr, da der Editor trotz Deiner angepassten shopware.yml Datei in einem Editor Feld keine unkompletten Tabellen mehr erlaubt. Ein Code der eine kompletten table html enthält (table tr td /td … td /td /tr /table ) wird nicht korrigiert. Ein unvollständiger Code wie tr td /td … td /td /tr /table wird aber komplett gelöscht. Gibt es hierfür einen Workaround / Lösung?
Der Fall ist dann schon etwas tricky, da die HTML Purifier Komponente schon richtig agiert, indem es invalides HTML säubert. Da du anscheinend sowieso schon den Block mit der Produktbeschreibung erweiterst, um dein Custom Field vorauszusetzen, könntest du jedoch einfach in der Produktbeschreibung valides HTML verwenden und den öffnenden table Tag dann bei der Ausgabe ersetzen.
Also in deiner Produktbeschreibung hast du ein valides table tag:
Danke - das ist eine super Idee und wenn es klappt, melde ich mich nochmal. Ich muss das erst mal end2end durchtesten. Deine Hilfe hier ist mega und sehr geschätzt. ICh hoffe, dass wir das irgendwie hinbekommen, damit nicht 3 Jahre Arbeit für die Tonne sind …
So, jetzt ist nach dem Testen leider wieder Ernüchterung eingekehrt.
Gute Nachricht: mit den Änderungen in der shopware.yml datei konnte ich wieder allen gewünschten Content / Tabellen über den Editor eingeben und speichern. Nur die Tags und kann ich trotz Einträgen in der .yml nicht über den Editor speichern.
Gute NAchricht 2:
Bei Eingabe von
{{ page.product.translated.customFields.description_table_header|raw }}
{{ page.product.translated.description|raw| }}
werden beide Tabellen (die in den Feldern angelegt sind) richtig formatiert ausgegeben
Schlechte NAchricht: Sobald ich an einer der Felder / Tabellen über |replace etwas entferne, wird der Rest vom Tabellen html code im template nicht mehr korrekt ausgegeben. Alle „<“ und „>“ werden umgewandelt in „<“ und "> " und damit als Text und nicht als Tabelle ausgegeben.
Mit Blick auf die Sanitize-Funktion wirkt der Blog-Beitrag aus dem Newsletter heute ja schon fast wie Satire :
Die Einkaufswelten aus Shopware 5 sind eine Erfolgsgeschichte. Das Feature ist sehr beliebt, hat einen hohen Bekanntheitsgrad und ist heute noch die perfekte Grundlage für erfolgreichen Content Commerce. Wir haben über die Jahre viele Erfahrungen und Feedback aus der Community gesammelt und dieses für die Entwicklung von Shopware 6 gebündelt und noch einige Schritte weitergedacht.
ich habe die z-shopware.yaml unter SWROOT/config/packages/z-shopware.yaml erstellt und den Code von dneustadt eingefügt. Dann Cache geleert und den Layout Editor neu geladen, funktioniert, allerdings teste ich das in Dockware Dev mit dem neusten Image, muss noch schauen wie das in den Live Umgebungen klappt.
Grundsätzlich ist die Verwendung von festgelegten Inhaltstypen auch einfacher, ein flüssiges Layout lässt sich damit auch besser umsetzen und der Aufbau ist für Content-Editoren leichter nachzuvollziehen. Im Reallife gibt es dann aber Kundenwünsche die diese strikte Logik nicht zulassen und sowas wie Inline Images erfordern.
Grundsätzlich ist die Verwendung von festgelegten Inhaltstypen auch einfacher, ein flüssiges Layout lässt sich damit auch besser umsetzen und der Aufbau ist für Content-Editoren leichter nachzuvollziehen.
Da gebe ich dir prinzipiell auch erstmal recht, leider fehlen mir im Erlebniswelten-Editor grundlegende Funktionen, um eigene halbwegs individuelle Seiten zu erstellen.
Nur mal als Beispiel: Man kann im Standard genau 4! Layouts für die Zeilen (Blöcke) wählen, 1 Spalte, 2 Spalten, 3 Spalten und 4 Spalten. Layouts wie 1/3 & 2/3, 1/4 & 3/4 usw. sind einfach nicht möglich, dabei gibt es doch basierend auf Boostrap da genug theoretisch Möglichkeiten. Von der „umfangreichen“ Auswahl der Elemente mal abgesehen.
Überall lese ich wie toll der neue Editor doch ist, gerade heute in einem Webinar mit dem Shopware Partner Manager wurde der Erlebniswelten-Editor als einer von drei Vorteilen von SW6 vorgestellt, das kann ich gar nicht nachvollziehen…
Der Editor ist zum aktuellen Zeitpunkt meiner Meinung nach nicht nutzbar (nur über individuelles HTML)!
The id name must contain at least one character, cannot start with a number, and must not contain whitespaces (spaces, tabs, etc.).
Wenn der Wert ungültig ist, wird das Attribute entfernt. Mit HTML5 wurde die Regel etwas abgeschwächt und erlaubt auch einzelne Zahlen als id. Das muss man im Purifier aktivieren über die Option Attr.ID.HTML5.
Ich hab die Option im GitHub Gist nachgepflegt: shopware.yml
Vielleicht darf ich mich auch noch mit einer Frage anschließen?
Ich hatte in vielen Kategorie-Seiten Rich Snippet Code für die FAQPages nach dem Schema: <script type="application/ld+json">...</script>
mit Hilfe von Text-Blöcken eingebunden.
Seit dem Update auf 6.5. ist natürlich alles von dieser „Sanitizer-Funktion“ rausgelöscht worden!
Kann man den Sanitizer auch davon abhalten, dieses zu entfernen?
PS: Natürlich stellt sich für mich auch die Frage, was diese ewige Gängelei von Shopware bezwecken soll…
Dass die unregulierte Ausführung von JavaScript die Security betreffend kritisch sein kann, darüber brauchen wir uns glaub ich nicht streiten. Darüber hinaus ist es weitläufig bekannt, dass das Einstreuen vereinzelter script Tags irgendwo im Markup alles andere als Best Practice ist. Trotzdem lässt sich die Verwendung erlauben. Wie das möglich ist kann man der bereits verlinkten Dokumentation zum HTML Purifier entnehmen.
Config um zusätzlich script Tags zu erlauben und deren Content nicht anzufassen:
@dneustadt: Vielen Dank für die schnelle Antwort!
Natürlich hast du Recht, dass Javascript nicht unkritisch ist und wildes Einstreuen nur Chaos verursacht. Aber erstmal muss man den Code in der Datenbank ablegen können, um darauf zugreifen und an der richtigen Position einpassen zu können! In Shopware 5 funktionierte das sehr gut mit Freitext-Feldern. Auch in den Versionen von Shopware bis 6.4.20. Ich weiß nicht, wie einige Plugins, welche Rich Snippets verwalten können, die Sanitizer-Korrektur umgehen?
Ich habe deine Einstellung natürlich gleich mal ausprobiert! Der Code wird jetzt nicht komplett gelöscht und auch in der Datenbank abgelegt, was schon mal sehr gut ist! Aber (leider) an einer Stelle umgeschrieben…
Und zwar ändert er am Anfang des Scriptes den Typ: <script type="application/ld+json"> um in <script type="text/javascript">
Hättest du vielleicht noch eine Idee?
HTML Purifier lässt sich soweit ich sehen kann nicht diesbezüglich konfigurieren. Das type Attribute ist für script Tags einfach vorgegeben. Möglicher Umweg: Mit JavaScript könnte man natürlich einfach ein weiteres script Tag an gewünschter Stelle anlegen mit einem beliebigem Type.
var script = document.createElement('script');
script.type = 'application/ld+json';
var content = {
// ...
};
var jsonContent = JSON.stringify(content, null, 2);
script.appendChild(document.createTextNode(jsonContent));
document.head.appendChild(script);
Hallo! Erstmal ein dickes Danke für deine Hilfe!
Schade, dass ein direktes Eingreifen in den Sanitizer nicht möglich ist. Das man doch irgendwo abschalten können!
Ich persönlich fühle mich unwohl bei dem Gedanken Code zu platzieren, um Funktionen, die Bewusst von Shopware integriert wurden, zu umgehen. Mir persönlich fehlt, als jemand, der sich Haupsächlich um das Frontend kümmert, dazu das fachliche Wissen, um genau zu verstehen, was ich da einfüge und welche weitere Auswirkungen das hat. Auch muss das alles dokumentiert werden, damit in Zukunft auch ein neuer Support des Shops weiß, was unter der Motorhaube gebastelt wurde.
Ich werde jetzt noch einmal schauen, ob ich doch noch einen Workaround zum korrekten Einfügen von Rich Snippets in Shopware 6 finde. Bisher war das negativ.
Abschließend möchte ich noch sagen: Ich habe noch nie so einen Grad an Frustration erlebt und so oft an meiner Intelligenz gezweifelt, wie bei der Migration von Shopware 5 auf Shopware 6. Welche Konsequenzen das für die Zukunft hat, kann ich noch nicht abschätzen.
Danke nochmal für den Code! Ich werde mir diesen auf jeden Fall ablegen!
Die Modifier müssen umgekehrt angewendet werden. Also so müsste es sein:
:
In Shopware 5 funktionierte das sehr gut mit Freitext-Feldern. Auch in den Versionen von Shopware bis 6.4.20. Ich weiß nicht, wie einige Plugins, welche Rich Snippets verwalten können, die Sanitizer-Korrektur umgehen?