Weitgehend update-sichere Templates

[noRiddle (revilonetz)]

Hallo Community.

Ich fänd' es sehr gut wenn man bei Updates nicht immer alle zu ändernden Template-Files durchgehen müsste.
Oft hat man nur ein paar Files geändert.
Mit einem bestimmten code-technischen Vorgehen könnte man sich viel Arbeit ersparen.
Dazu habe ich ein Ticket mit einem Vorschlag aufgemacht: Ticket #2419

Was haltet Ihr davon ?
Insbesondere auch Entwickler und Dienstleister.

Gruß,
noRiddle

Linkback: https://www.modified-shop.org/forum/index.php?topic=42765.0

[web4design]

Finde ich eine sehr gute Idee.

Durch die Trennung sieht man recht schnell, was wirklich geändert wurde.
Man muss nicht alles mergen.
Zudem kann man eine Datei einfach löschen und es wird auf die Orginaldatei zurückgegriffen.

Dein Nachtrag, die Verortung im Template selbst, hätte ich angeregt, stände er nicht schon da.
Sollte man mal mehrere Templates im Ordner haben, gäbe es sonst ggfs. Zuordnungsprobleme.

[Viol]

Ich fände es sehr sinnvoll, jede Vereinfachung von Updates ist zu begrüßen.

[voodoopupp]

Auch in finde das einen interessanten Ansatz. Wie genau das allerdings wirklich umsetzbar und pflegbar ist, sei mal dahingestellt.

In der Tat brauche ich beim Update immer mit am längsten, alle Dateien des Templates zu aktualisieren, denn man befolgt ja dann bei einem eigenen Template diese Anleitung und geht dann Datei für Datei durch:
https://www.modified-shop.org/wiki/Tutorial:_Template_eines_xt:Commerce_Shops_in_der_modified_eCommerce_Shopsoftware_weiter_verwenden

Grüße
Dominik

[noRiddle (revilonetz)]

Genau so ist es.
Mit meinem Vorschlag, oder auch ähnlich umgesetzten Ideen, mußt du diese Anpassungen eben nur noch für die Files machen die du geändert hast und die folglich im Ordner /custom/  liegen.

Für CSS würde ich einen Ansatz vorschlagen wie er für Javascript bereits gemacht ist.
Das mache ich inzwischen für jeden meiner Betreuten. D.h. einen Hook in die general.css.php  einbauen, welcher alle Dateien in /css/extra/  lädt und mit komprimiert, sodaßß man mittels einer dort hinterlegten z.B. custom_styles.css  eigene Styles verwirklichen, bzw. vorhandene überschreiben kann.

Template-Bauer könnten das übrigens auch verwenden, wenn nicht ein komplett anderer Ansatz gewählt wird und somit so gut wie alle Dateien vom Standard abweichen.

Ich verstehe gar nicht die Vorbehalte. Auch Torsten hat ja im Ticket einen Vorbehalt geäußert.
Entweder jemand hat seine Dateien gepflegt oder nicht. Da ist es egal, ob es ist wie es jetzt ist, oder mein Vorschlag realisiert wurde.
Im zweiten Fall jedenfalls dürfte es in den meisten Fällen um Längen einfacher sein upzudaten.

Gruß,
noRiddle

[Karl1]

Hallo Zusammen,
ich finde den Vorschlag von noRiddle super.

Die im Ticket genannten Vorbehalte habe ich gelesen, kann sie aber nicht nachvollziehen.

Wer die Möglichkeit von Custom-Templates nicht nutzen möchte, der braucht das auch nicht.
Es sind ja auch Module in Modified integriert die nicht jeder braucht und nutzen will – trotzdem werden sie optional angeboten.
Warum dann nicht auch die Chance eines updatesicheren Templates.
Vielleicht hilft es die Bedenken aus dem Weg zu räumen, wenn ein Schalter im Admin die Option aktiviert bzw. deaktiviert.

Markus weist im Ticket auf den smarty-Ordner im Template hin.
Mittels einer eigenen Smarty-Template-Funktion die Ausgabe umzuleiten macht aus Gründen der Performance keinen Sinn, weil in diesem Fall die ursprüngliche und die custom Templatedatei von Smarty verarbeitet werden müssen.

Der gemachte Vorschlag sollte aus meiner Sicht unbedingt umgesetzt werden.

Gruß Karl

[noRiddle (revilonetz)]

...wobei in der Tat RobinTheHoods Anregung im Ticket, mit dem {block}-Feature von Smarty, in Zukunft der Weg sein könnte.
Das Gute an meinem Vorschlag ist imo, daß er sich blitzschnell umsetzen ließe.
Mit den Regex die ich im Ticket gepostet habe kann man alle erforderlichen Dateien in allen Verzeichnissen mit einem Schlag anpassen.

Wer's nicht gesehen hat:
Torsten hat im Ticket darum gebeten die dort gemachten Kommentare in diesen Thread zu übertragen.

Gruß,
noRiddle

[RobinTheHood]

Aus dem Ticket: #219

Ich finde die Herangehensweise von noRiddle auch gut.

Zudem könnte man auch noch etwas weiter denken. Die Smarty Template Engine bietet von Haus aus einiges an Funktionalität, mit der man die Templates und die Darstellung von Modulen updatefähig gestallten könnte. Siehe ​https://www.smarty.net/docs/en/advanced.features.template.inheritance.tpl und ​https://www.smarty.net/docs/en/language.function.block.tpl

Die Templates müssten dafür nach einer festen Konvention aufgebaut werden und in entsprechende Blöcke aufgeteilt werden. Das wäre dann vielleicht eher ein übernächster Schritt, den man aber vielleicht im Hinterkopf bei der Planung behalten könnte. Zudem müsste es noch einen Loader als SmartyPlugin geben, der die Pfade automatisch für Smarty auflösen kann.

Insgesamt finde ich die Idee spannend.

Mit besten Grüßen
Robin

[voodoopupp]

Also generell finde ich die Idee nicht schlecht. Egal wie, eine Vereinfachung in der Pflege des Templates wäre sehr willkommen! Als Shopbetreiber muss ich sagen, dass ich immer wieder den Aufwand habe, beim eigenen Template die ganzen Änderungen einzupflegen.

Da das Template ja selbst erstellt wurde bzw. an den entsprechenden Stellen verändert wurde, damit unser Design passt, wurden über die Jahre einige Änderungen an Dateien so gebaut wie gewünscht. Hinzu kamen natürlich auch die ein oder andere Zusatzfunktion...
Welche Dateien aber die wirklich veränderten sind und vom Standardtemplate abweichen, würde mir meines Erachtens ein "Custom" Ordner leichter anzeigen.

Aktueller Stand:
wenn also ein Update kommt gehe ich jede abweichende Datei durch und schaue, was ich anpassen muss. Dafür nutze ich den entsprechenden Wiki-Eintrag:
Tutorial: Template eines xt:Commerce Shops in der modified eCommerce Shopsoftware weiter verwenden

Davon ist aber meist ein großer Teil eigentlich Standard und wird von mir entweder als Standard-Modified Code verwendet oder wird von mir teilweise gar nicht verwendet.
Dennoch habe ich nicht alles im Kopf, welche Datei es alles betrifft bzw. wenn ich mal schnell irgendeine Datei leicht modifiziert habe, habe ich mir das vielleicht mal eben nicht notiert.

Ein Custom Ordner könnte folgendermaßen helfen:
wenn nun ein Update kommt, dann mache ich einen Merge aus altem Standard-Template und neuem Standard-Template und extrahiere die geänderten Dateien.

Nun habe ich also die notwendigen Dateien fürs Update.

Nun nochmals einen Merge mit meinem Custom Ordner, welcher ja die für mich wirklich notwendigen Änderungen enthält.
Dann fallen nochmals alle Dateien raus, die simpel im Standard übernommen werden können.

Nur die gematchten Dateien müssen wirklich von mir überarbeitet werden.

Mit dem Custom Ordner habe ich auch nicht das Problem, dass ich evtl. mal vergessen habe mir irgendwo zu notieren, welche Dateien ich so verbogen habe, dass sie niemals mehr Standard sein dürfen!

Grüße
Dominik

[Q]

Bin auch dafür. Aktuell handhabe ich das so, dass die geänderten Dateien lokal in der Verzeichnisstruktur kopiert werden und beim Update ich das Update inkl. original Templateupdate bei der Onlineversion drüber bügel. Anschließend dann die lokal gespeicherten Dateien mit der Templateupdateanleitung abgleiche und diese dann auf die Onlineversion rüber ziehe. Im Prinzip wie die Lösung mit dem custom Ordner, nur eben Lokal statt im Templateordner (online).

Von Smarty habe ich keine Ahnung. Deswegen dazu keine Bewertung.

[RobinTheHood]

Hallo und guten Abend,

ich hätte ebenfalls ein Implementierungsvorschlag / Prototype. Wie stelle ich den hier mal am besten vor? Es ist ein wenig mehr Quellcode, da ich mehrere Klassen einführe. Ich weiß nicht, ob es gewünscht und sinnvoll ist, hier im Forum so viel Quellcode zu posten. 🤔 Ich würde sonst vielleicht ein Github Gist erstellen.

Mit besten Grüßen
Robin

[noRiddle (revilonetz)]

Als GitHub Gist dürfte es übersichtlicher werden, wenn es dir keine Arbeit macht. Mich interessiert's jedenfalls.

Gruß,
noRiddle

[RobinTheHood]

Hallo,

ich habe hier ein Implementierungsentwurf auf Github als Gist erstellt. Es wurde mit modified Version >=2.0.6.0 getestet. Er arbeitet mit Vererbung. Eine kurze Erklärung ist im Quellcode als Kommentar verfasst, samt Beispiel.

Der Vorschlag von noRiddle ist besser abwärtskompatible. Mein Vorschlag benötigt einiges mehr an Anpassung. Mir gefällt er zwar gut, aber ich weiß nicht ob ich ihn empfehlen kann. Er kann zu deutlich mehr Problemen führen, wenn sich User ihr System individuell angepasst haben und Pfade zum Template selbst generieren werden. Kommt drauf an wie risikobereit man ist alte Zöpfe abzuschneiden. In meinem Vorschlag sollten nur noch folgende Ausdrücke verwendet werden:

Code: PHP  [Auswählen]

$template->getPath('...');
$template->fetch($smarty, '...');
$template->display($smarty, '...');

https://gist.github.com/RobinTheHood/94563bdcc3d12366104d36c13670270f

Egal wo die Reise hingeht. Einen Weg in die Richtung, die Templates updatefähiger zu gestalten, würde ich befürworten.

Mit besten Grüßen und einen schönen Abend
Robin

[Karl1]

Hallo Robin,
habe mir deinen Vorschlag mal in einen 2.0.6.0 Shop eingebaut.

Als erstes zeigt sich eine weisse Seite - Class 'TemplateException' not found.
Alle Vorkommen von TemplateException in Exception geändert.

Anschließend habe ich die Dateien
- templates/my_template/index.html und
- templates/my_template/module/product_info/product_info_tabs_v1.html
erstellt und verändert.
Von den gemachten Änderungen ist im Shop nichts zu sehen - es ist also nicht so einfach ein Override zu erstellen.

Ich finde dein Ansatz ist zu aufwendig, warum soviel mehr PHP-Code?
Neben zahlreichen zusätzlichen Abfragen "file_exists", muss eine JSON-Datei gepflegt und gelesen werden.
Wesentlich schneller ist eine einzelne Abfrage "is_file", wie noRiddle sie vorgeschlagen hat.

Gruß Karl

P.S.: Kann es sein, dass dein Vorschlag in MMLC-updatefähige Templates zielt?

[RobinTheHood]

Hallo Karl,

der Entwurf ist ganz unabhängig vom MMLC. Es ist ein Entwurf / Konzept. Es könnten z. B. wie bei noRiddles Vorschlag alle Codestellen mit einer Regex in modified angepasst werden, die noch fehlen. Im Github Gist sind nur Beispiele aufgelistet. Ich habe keine Möglichkeit im SVN Pull Request zu machen, sonst hätte ich wohl einen PR mit einer vollständigen Implementierung bereitgestellt.

Die Anzahl der file_exists() Abfragen ist pro Request gering. Zudem hat die Funktion von Haus aus einen eingebauten Cache. Siehe: https://www.php.net/manual/en/function.file-exists.php Ich kann mir kaum vorstellen, dass das im Millisekunden Bereich oder schlechter ist. Sollte es doch für jemand wirklich von Relevanz sein, könnte man das durch zusätzliches Caching weiter reduzieren. Bei mir war es nicht notwendig.

Viele Systeme mit denen ich arbeite verwenden Themes oder Templates mit Vererbung. Als Beispiel könnte ich hier Shopware, PrestaShop und Gamio nennen. Mit weniger Quellcode habe ich einen derartigen Ansatz nicht umsetzten können.

Mit besten Grüßen
Robin