Question or Bug: Check for Backend or Frontend Mode

[tarun-uwe]

Hi,

beim Öffnen eines Backend Moduls mit InsertTags {{iflng::}} - welche das Modul als Label nutzt, kommt es zu einem Fehler, da die InsertTags ersetzt werden. Die Frage ist, ob nicht ein Prüfung auf Backend oder Frontend Mode durchgeführt werden sollte, damit InsertTags nicht ersetzt werden.

Code Zeile aus dem Utils Bundle

https://github.com/heimrichhannot/contao-utils-bundle/blob/7eb92292a95946ae71a1ba80f95ab88971e279bb/src/Form/FormUtil.php#L294-L296

StackTrace Fehler:

[Defcon0]

Hallo,

nun hast du genau den interessanten Teil abgeschnitten :-) Welcher Fehler ist es denn genau?

Der Aufruf, den du beschrieben hast, ist ein ganz normaler replaceInsertTags()-Aufruf. Es muss also eher am Wert liegen als am Aufruf.

Und poste bitte mal deine Abhängigkeiten aus der composer.json.

[tarun-uwe]

Hi,

der Fehler ist, dass im Backend es kein objPage gibt, wenn der iflng Tag geprüft wird. Aber eigentlich sollte im Contao Backend ein InsertTag ja nicht ersetzt werden, oder?

Der Fehler tritt bei der Label Generierung in https://github.com/Netzhirsch/CookieOptInBundle/blob/196d3031e1735b7b82c08198d9460add6f9420a2/src/Resources/contao/dca/tl_module.php#L439-L447

Das ist die komplette Fehlermeldung

[Defcon0]

Gute Frage. Ich weiß nicht, ob InsertTags was mit dem Scope (BE oder FE) zu tun haben. Wir könnten maximal im FormUtil prüfen, ob der String leer ist und dann nicht replacen. Aber ich vermute, dass der Fehler eher an der Quelle zu suchen ist, wo schon etwas leeres in den Inserttag reingereicht wird?

[tarun-uwe]

Ich glaube das habe ich falsch formuliert. Der InserTag ist nicht leer.

Anbei ein Beispiel:

{{iflng::de}}Externe Medien{{iflng::en}}Extern Media{{iflng::ja}}Extern Media{{iflng::zh-CN}}外部媒体{{iflng}}

Wenn ich im Backend das Modul öffnen und bearbeiten möchte, versucht FormUtil u.a. diese InsertTags zu replacen. Im Contao Core ist die Funktion seit Version 4.12 anders aufgebaut. Der Fehler erfolgt nur im Backend Mode bei LocaleUtil::formatAsLocale($GLOBALS['objPage']->language)

Beispiel Ablauf Frontend: www.example.de/en/xyz --> $GLOBALS['objPage']->language hat den Wert 'en' und dieser wird als String übergeben und kann dann gegen die InserTags geprüft werden.

Beispiel Ablauf Backend: www.example.de/contao?do=themes&table=tl_module&id=177&act=edit --> $GLOBALS['objPage'] existiert nicht, da kein Seitenbaum / Seite für das Contao Backend vorhanden ist. Somit wird kein String sonder null übergeben.

Aus Contao Sicht ist das auch okay und es muss hier keine Prüfung stattfinden, da InsertTags im Backend nicht ersetzt werden sollen. Im Frontend ist die Sprache im Frontend immer verfügbar, da es ein Pflichtfeld ist.

[Defcon0]

da InsertTags im Backend nicht ersetzt werden sollen

Gibt es dafür eine Quelle? Wenn es so wäre: warum wird es dann nicht in Controller::replaceInsertTags() geprüft? Da müsste man in allen möglichen Stellen prüfen? :-/

[tarun-uwe]

Hi Defcon0,

die Info habe ich hierher: https://contao.slack.com/archives/CK4J0KNDB/p1631198523375000

Ich frage mich, ob es jemals vorgesehen war, InsertTags im Backend zu nutzen. Verstehe, dass nur weil der Core das nicht tut, es ja vielleicht eine gute Idee wäre es dennoch zu ermöglichen. Die Frage ist ja explizit spannend für die InsertTags die von einer Seitenbaum Variable abhängig sind, wie diese sich in einem Backend Moder verhalten sollten.

[Defcon0]

Hi,

kannst du bitte mal in der Klasse FieldPaletteWizard die Zeile 277

$args[$key] = $formUtil->prepareSpecialValueForOutput($fieldName, $value, $dc, ['_dcaOverride' => $this->dca['fields'][$fieldName]]);

durch folgendes ersetzen:

$args[$key] = $formUtil->prepareSpecialValueForOutput($fieldName, $value, $dc, ['skipReplaceInsertTags'=>true, '_dcaOverride' => $this->dca['fields'][$fieldName]]);

und dann in FormUtil auf skipReplaceInsertTags prüfen und falls es gesetzt ist, dann kein replaceInsertTags() machen und schauen, ob du noch weitere Probleme bekommst?

Ich schrecke etwas davor zurück, diese Änderung zu machen, da es bis dato nie Probleme gemacht hat und ich nur schwer abschätzen kann, ob das dann woanders etwas kaputt spielt.

[Defcon0]

Und ist dann am Ende nicht eher das Netzhirsch-Plugin das Problem, weil es im Backend einen Inserttag verwendet, der nicht für das Backend geeignet ist? Wo wird der denn genau genutzt? Das habe ich in deren Code nicht gefunden.

[tarun-uwe]

Hi,

die Änderungen haben gewirkt. Netzhirsch-Plugin ist indirekt das Problem.

Wir benutzen im Backend die InsertTags welche sich auf die Sprache beziehen. Das müssen wir machen, weil sonst die Erweiterung sich nicht sinnvoll für Multi-Language Websites nutzen lässt.

Zur Übersicht, benutzt im das Plugin im Backend die Funktion die definierten Gruppennamen hinter den einzelnen Einträgen darzustellen. An sich ein gutes Feature.

Beispiel:

Aktueller Fall: Wir müssen jedoch zur Ausgabe im Frontend in die Gruppenbezeichnung auch die InsertTags nutzen. Screenshot, wies es nun mit den zwei Änderungen aussieht.

Ich schrecke etwas davor zurück, diese Änderung zu machen, da es bis dato nie Probleme gemacht hat und ich nur schwer abschätzen kann, ob das dann woanders etwas kaputt spielt.

Das kann ich nachvollziehen, die Frage ist für mich, ob das ein Case ist, der nie so angedacht ist oder aber im Core angefangen werden müsste.

[koertho]

Der Fehler liegt aus meiner Sicht im FieldPaletteWizard und die Lösung ist so aus meiner Sicht korrekt (der skip-Parameter). Wenn im Backend keine Inserttags verwendet werden dürfen, sollte FieldPaletteWizard die entsprechende Konfiguration setzen. Die prepareSpecialValueForOutput-Methode ist ein Util, welches man dem Kontext entsprechend benutzen sollte.

Also schlage ich folgende Änderungen vor:

• Einbau des Skip-Parameter in die prepareSpecialValueForOutput-Methode
• Setzen des Skip-Parameters im FieldPaletteWizard (sollte im Bezug auf Labels keine ernsthaften Probleme machen), wenn im Backend

[Defcon0]

Ich habe in 2.205.0 in FormUtil::prepareSpecialValueForOutput() einen Parameter skipReplaceInsertTags eingebaut. Dieser wird im neuen Release vom field-palette-bundle verwendet (0.5.5). Bitte teste mal, ob es dein Problem löst.

[koertho]

@Defcon0 Ich würde den Skip-Flag nur setzen, wenn im Backend. Es könnte sein, dass das Label auch im Frontend ausgegeben wird. Ich weiß nicht, inwiefern wir uns dann darauf verlassen können, dass das später nochmal ersetzt wird (durch Contao). Oder was meinst du?

[Defcon0]

Den Gedanke hatte ich auch, habe ihn aber verworfen, da es diese Label-Callbacks nur im Backend-Kontext gibt. Aber an so einer zentralen Stelle könnte man es auch so bauen, dass man auch das theoretische Risiko ausschließt. Ich baue den Check mit ein.

[tarun-uwe]

Hi @Defcon0 & @koertho krankheitsbedingt konnte ich noch nichts testen. Braucht ihr von mir noch ein Feedback oder wird das so veröffentlicht? Vielen Dank erst mal schon.

[koertho]

@tarun-uwe Beide Updates sind schon raus, also einfach mal testen ;)