neben Twig Templates die .hmtl5 behalten?

[HBR]

Hallo,

allgemein Frage. Stelle gerade sämtliche php basierten html5 Templates (meist rsce) auf twig um. Sollte ich die alten .html5 Templates im Templates-Ordner belassen oder können diese gelöscht werden?.

[mlweb]

Die musst Du m.E. löschen. Contao kann nicht mit gleichnamigen html5 und twig-Templates umgehen. Du brauchst diese ja auch nicht mehr, wenn Du die Twig-Templates benutzt.
Nur zu Sicherheit - die Konfigurationstemplates von Rocksolid darfst Du natürlich nicht löschen.

[HBR]

Die musst Du m.E. löschen. Contao kann nicht mit gleichnamigen html5 und twig-Templates umgehen. Du brauchst diese ja auch nicht mehr, wenn Du die Twig-Templates benutzt.
Nur zu Sicherheit - die Konfigurationstemplates von Rocksolid darfst Du natürlich nicht löschen.

Bei den RSCE Templates war ich mir ziemlich sicher, dass ich die alten html5 Templates löschen kann, bei anderen bin ich mir da nicht so sicher. Nur so als Beispiel. Ich hatte durch einen Anwenderfehler bei mehreren Modulen über "mehrere bearbeiten" (News-Listen/simple) aus Versehen bei einem Modul auf ein Template umgestellt, was ich eigentlich gar nicht wollte. Ein zurückstellen auf das alte war nicht mehr möglich, weil es nicht mehr in der Template-Auswahl des Moduls zur Verfügung stand. Ich musste zuerst wieder ein html5 Template anlegen (Template-Ordner -> neues Template), umbenennen/neu benennen, dieses innerhalb des Moduls auswählen und davon dann die Twig-Variante erzeugen. Esrt dann hat es wieder funktioniert.

Sorry, kleine Korrektur, es war nicht das news-simple, sondern mod_navigation.

[Spooky]

Grundsätzlich kannst du sie behalten, die stören nicht. Bzgl. RSCEs weiß ich es allerdings nicht genau, probiere es doch einfach aus?

[HBR]

Grundsätzlich kannst du sie behalten, die stören nicht. Bzgl. RSCEs weiß ich es allerdings nicht genau, probiere es doch einfach aus?

Mein ganzes Leben ist ein einziger Versuch

Also bei RSCE hatte ich es bereits versucht, da scheint beim Löschen nichts anzubrennen, bei allem anderen würde ich sagen, dass man sie behalten soll, da hier ja mal zumindest bei mir der Fall aufgetreten ist, dass im Backend die Templates in den Modulen nicht mehr zur Auswahl standen und die Vermutung nahe lag, das Contao zur Auswahl die hmtl5 Templates benötigt und sofern ein namentlich passendes Twig-Template vorliegt, dieses im Frontend vorzieht.


Ergänzung:
Habe gerade noch einen Test gefahren mit der Erweiterung "Bild pro Seite festlegen ". Dort hatte ich das Template "mod_pageimage" als Twig-Variante umgesetzt und das html5 Template gelöscht. Im Backend wird mir im Modul bei den Template-Einstellungen: "Unbekannte-Option: ........" angezeigt. Im frontend wird aber problemlos das Twig-template ausgegeben. Also html5 Template wieder reingelegt und schwups wird es auch im Backend wieder angezeigt. Also behalten heisst die Devise

[HBR]

... Contao kann nicht mit gleichnamigen html5 und twig-Templates umgehen .....

Dem würde ich jetzt widersprechen. Oder ich verstehe dich falsch. Ich habe ein mod_pageimage.html5 und ein mod_pageimage.html.twig Template und dies scheint in contao wunderbar zur funktionieren.

[mlweb]

Ich hatte zumindestens in Contao 4.13 (oder 4.12) das Problem, dass es nicht möglich war, gleichnamige html5- und twig-Templates im gleichen Ordner liegen zu haben das hing mit dem gemanaggten Namespace zusammen, wenn ich das damals richtig verstanden habe https://docs.contao.org/dev/framewor...aged-namespace.
Ich hatte bisher auch noch nie das Problem, dass ich das html5-Template zusätzlich gebraucht hätte. Das zunächst "unbekannte Option" dort steht halte ich für nicht unnormal. Das zuvor ausgewählte html5-Template existiert ja nicht mehr und wenn Du nicht im Dev-Modus bist oder die Symfony-Caches gelöscht hast, ist das Twig-Template ja noch unbekannt.

[HBR]

Du nicht im Dev-Modus bist oder die Symfony-Caches gelöscht hast, ist das Twig-Template ja noch unbekannt.

Das mit dem Cache/Debug-Mode hatte ich bereits gecheckt. Hatte bei mir keinen Einfluss auf die Anzeige in der Template-Auswahl. Zumindest scheint es im Moment ratsam zu sein, beide Templates (html5/twig) zu behalten, RSCE lasse ich mal Außen vor.

[Kopfnuss]

Ich bin gerade in der gleichen Situation wie du, stelle alle Templates auf Twig um, wo ich es kann.
Dabei lösche ich danach das html5 Template und hatte damit noch kein Problem. Ich wüsste als Laie auch nicht, warum Contao noch das html5 Template benötigen sollte; das ergibt für mich einfach keinen Sinn. Ich sehe da eher ein Potenzial für Fehlerquellen oder Verwirrung.

[HBR]

...Dabei lösche ich danach das html5 Template

ich sehe das ähnlich, habe es auch gerne aufgeräumt. Warum Dateien in einem Verzeichnis haben, wenn sie keinen Nutzen mehr haben. Allerdings stört mich sehr viel mehr, dass im Modul in den Template-Einstellungen "Unbekannte-Option" steht. Kannst du dies bestätigen, dass dies bei dir auch so ist?

[Kopfnuss]

ich sehe das ähnlich, habe es auch gerne aufgeräumt. Warum Dateien in einem Verzeichnis haben, wenn sie keinen Nutzen mehr haben. Allerdings stört mich sehr viel mehr, dass im Modul in den Template-Einstellungen "Unbekannte-Option" steht. Kannst du dies bestätigen, dass dies bei dir auch so ist?

Nein, das steht bei mir nicht. Ich habe da am Beispiel von einem custom download-element: "content_element/download/download_with_bg_color [Global]" stehen.
Kann es sein, dass du in der config noch den Support für das html5-Element drinstehen hast? Cache löschen? Debug-Modus an machen?

Edit: das mein ich https://github.com/contao/contao/blo...ntent-elements

[HBR]

Kann es sein, dass du in der config noch den Support für das html5-Element drinstehen hast? Cache löschen? Debug-Modus an machen?

Nö, Cache ist gelöscht. womöglich hängt es damit zusammen, dass es sich nicht um content-elemente handelt, sondern um Modul-Templates wie mod_pageimage.

[Kopfnuss]

Nö, Cache ist gelöscht. womöglich hängt es damit zusammen, dass es sich nicht um content-elemente handelt, sondern um Modul-Templates wie mod_pageimage.

Haben diese Templates schon Twig-Support? Siehe: https://github.com/contao/contao/tre...templates/twig
Wie kannst du dann dein Template auswählen?
Ich setze nur Twig-Templates für das Element, um die unter dem oben genannten Link sind.

[Spooky]

Du kannst PHP Templates auch mit Twig Templates ersetzen. Also mod_newslist.html5 funktioniert genau so wie mod_newslist.html.twig.

[HBR]

Du kannst PHP Templates auch mit Twig Templates ersetzen. Also mod_newslist.html5 funktioniert genau so wie mod_newslist.html.twig.

Stimmt, nur eben scheint es der Fall zu sein, zumindest bei mir, wenn man dann das html5 Template löscht, in der Template-Auswahl des Moduls auf einmal "Unbekannte-Option" auftaucht. Das war auch der Ausgangspunkt meiner Frage weiter oben, ob man die html5-Templates behalten sollte.

[Spooky]

Stimmt, nur eben scheint es der Fall zu sein, zumindest bei mir, wenn man dann das html5 Template löscht, in der Template-Auswahl des Moduls auf einmal "Unbekannte-Option" auftaucht. Das war auch der Ausgangspunkt meiner Frage weiter oben, ob man die html5-Templates behalten sollte.

Dazu musst du mehr Informationen liefern. Poste den Pfad des Templates, das du gelöscht hast und dessen Inhalt. Poste auch einen Screenshot deines Template Ordners.

[HBR]

Dazu musst du mehr Informationen liefern. Poste den Pfad des Templates, das du gelöscht hast und dessen Inhalt. Poste auch einen Screenshot deines Template Ordners.

oh, jetzt wo du es ansprichst könnte es natürlich sein, dass die mod_ Templates alle in einen eigenen Unterordner gehören müssen, so wie die Content-Templates ja auch alle in einem eigenen Unterordner liegen (templates/content_element). Bei mir liegen im Moment alle mod_ Templates, egal ob html5 oder twig im gleichen Verzeichnis "Templates", Bsp.:

--Templates
---mod_pageimage.html5
---mod_pageimage.html.twig

[Spooky]

Das content_element (und frontend_module) Unterverzeichnis gilt nur für neue Inhaltselemente bzw. Module, die als Fragments via Twig umgesetzt sind. Für die PHP Templates (und Twig Templates die PHP Templates ersetzen) gilt weiterhin die alte Logik.