Questions & Answers

[daniel_philippi]

Hallo Zusammen.

Habe wohl einen Bug gefunden.

Ich verwende convertEntities="quote" bei jedem CMS_INPUT_TEXT. Es funktioniert auch wurderbar, allerdings nur bei Elementen die nicht in einer FS_LIST sind. Die in der FS_LIST bekomme ich nur konvertiert, wenn ich bei der Ausgabe noch convert2() aufrufe.

Ist das ein Bug oder hat das schonmal jemand beobachtet und evtl. gehabt und behoben?

Viele Grüße,

Daniel Philippi

[andre]

convertEntities ist der Legacyweg aus 3.1er Zeiten. Der convert2()-Aufruf im Template ist hier genau der Weg der Wahl.

Das Attrbiute wird hier  fälschlicherweise als unterstuetz angezeigt. Das wird nun entsprechend angepasst. Danke fuer die Meldung

InterneID: #101695

[daniel_philippi]

Gerne.

Nun ist es so, dass ich alle CMS_INPUT_TEXT Eingebeelemente auf convertEntities="quote" umgestellt habe, da dies für mich die elegantere Art war. So ist der Fehler erst rausgekommen.

Muss/sollte ich diese nun alle auf .convert2() umbauen, damit ich mit späteren Versionen von FirstSpirit kompatibel bleibe oder ist sichergestellt, dass dort wo es aktuell funktioniert auch weiterhin funktionieren wird?

Viele Grüße,

Daniel Philippi

[matthiasforberg]

Hallo,

blöde Frage: wenn das nicht schon 2011 mehr unterstützt wurde, warum ist es in 5.0 immer noch drin??? Ich bin grad über den gleichen Fehler gestolpert und auch bei mir funktioniert es nicht in Linktemplates.

Außerdem habe ich ein neueres Thema gefunden, in dem dieser Effekt als "internal issue" bezeichnet wird: https://community.e-spirit.com/message/14013#14013

Was gilt denn jetzt?

[Peter_Jodeleit]

Wo genau ist es "noch drin"? Hier geht es ausschließlich um "FS_LIST". In dem von dir verlinktem Posting geht es um (Text-)Felder innerhalb von Links.

[EDIT]

Das im referenzierten Posting angesprochene Problem ist seit 5.0R4 behoben.

[matthiasforberg]

Ok, sorry! Ich dachte, es geht um die Felder innerhalb von FS_LIST, also z.B. auch Linkvorlagen.

zum [EDIT]: ich habe eine 5.0.425 und da wird z.B. ein convertEntities="quote" an einem Textfeld richtig ersetzt, wenn das CMS_INPUT_TEXT sich in einer Seitenvorlage befindet, aber nicht, wenn es in einer Linkvorlage ist (die über FS_LIST eingebunden ist).

Ich kann das aber gerne in dem anderen Thread weiter diskutieren, wenn das hier nicht hin gehört.

[Peter_Jodeleit]

Noch ein Hinweis: Es stimmt, das mittlerweile üblicherweise bei der Ausgabe ".convert" bzw ".convert2" benutzt wird. Das hat den Hintergrund, das man so feingranularer steuern kann, wo Zeichen wie ersetzt werden. Trotzdem sollte das Attribut "convertEntities" an den Eingabekomponenten funktionieren. Wenn es das nicht tut, sollte das behoben werden. Wobei der beste Weg ist, sowas über den Helpdesk als Ticket laufen zu lassen.

[matthiasforberg]

Okay, danke trotzdem für die Hilfe. Ich habe grad noch rausgefunden, dass es in Linkvorlagen funktioniert, wenn direkt aus der Linkvorlage auf das Textelement zugegriffen wird, aber nicht, wenn diese z.B. in einer anderen Vorlage über eine Schleife läuft und die einzelnen Linkattribute in dieser Form geholt werden: $CMS_VALUE(forLink.lt_text)$

Ich werde mich damit ans Helpdesk wenden.

[Peter_Jodeleit]

Das "convertEntities" wirkt sich nur auf den gemappten Wert in der Vorlage aus (also $CMS_VALUE(attribut-Name)$). Wenn direkt auf das Feld zugegriffen wird wie in deinem Beispiel, arbeitet man mit dem "rohem" Wert. Das müsste auch so dokumentiert sein. Vielleicht kann man das aber noch mal klarer formulieren, um weitere Missverständnisse zu vermeiden.

[mbergmann]

Hallo,

Ergänzend dazu noch ein paar Gründe warum man die Konvertierung besser in der Ausgabe (und dort auch erst "ganz am Schluss") macht:

Ein (zugegebenermaßen wohl eher seltener) Anwendungsfall kam mir letztens in einem Projekt unter: Dort hat man sich nachträglich entschieden, dass externe Links über eine Absprungseite geleitet werden sollten, die den "Namen" der Seite (quasi den Link-Text) als URL-Parameter bekommt und dann mit JS einen entsprechenden "Weiter"-Button baute. Hierzu musste aber der Original-String URL-encoded werden (was etwas ganz anderes ist). D.h. hier musste dann convertEntities ausgeschaltet werden und es waren einige Template-Anpassungen notwendig. Das lässt sich aber natürlich verallgemeinern auf ähnliche Fälle.

Generell führt die Formular-Konvertierung bei der Weiterverarbeitung von Werten z.B. in Rendertemplates potenziell zu Problemen: Hier will man meistens den "Original-String" haben und nicht den schon konvertierten.

Hinzu kommt, dass an einigen Stellen keine Konvertierung geschehen kann, z.B. wenn man Texte in Tabellenvorlagen mit #row.text ausgibt oder auch über ein ContentSelect.

Das führt zu dem grundsätzlichen Problem, dass man (bei der Verwendung von convertEntities) an einigen Stellen mit konvertierten und an anderen mit unkonvertierten Texten arbeitet bzw. arbeiten muss und hier den Überblick behalten muss. Gerade bei der Verwendung von Rendertemplates / Scripten ist es dann unnötig komplex und fehleranfällig, immer nachzuvollziehen wo / ob ein konvertierter und wo ein unkonvertierter Text vorliegt.

Vergessene / doppelte Konvertierungen fallen auch selten sofort auf, weil sie ja immer erst auftreten wenn ein Redakteur in den entsprechenden Komponenten einen Text eingibt, der durch die Konvertierung verändert wird.

Meine Empfehlung ist hier immer, solange wie möglich mit den Original-Strings zu arbeiten, d.h. in Formularen kein convertEntities zu nutzen, auch keine Übergabe von konvertierten Strings an Rendertemplates oder Scripte usw. Die Konvertierung sollte immer erst "ganz am Ende" - also dort wo der String wirklich ausgegeben wird mit convert / convert2 geschehen. Diese Variante kann nämlich konsequent einheitlich umgesetzt werden.

Viele Grüße

Michael