Nehmen wir folgendes an: wir haben einen neuen Oxid 6.2 Shop und verwenden ein Twig-Theme. Fragen, die ich mir stelle betreffen die Kompatibilität mit Modulen, die auf Smarty aufbauen. Wie ist hier die beste Strategie?
Kann man Twig und Smarty selektiv für bestimmte Bereiche aktivieren? Oder lieber noch abwarten, bis die benötigten Module auch Twig unterstützen?
Die Annahme das die Entscheidung pro Twig gefallen ist bedeutet, dass Du wahrscheinlich für die Mehrzahl der Module wenn nicht sogar für alle Module tätig werden musst um deren Template-Erweiterungen in Deinen Shop zu bekommen. Voraussetzung die genutzten Module nicht verschlüsselt, dies könnte es unnötig erschweren.
Beste Strategie wäre es für jedes Modul ein eigenes Sub-Modul zu programmieren, welches notwendige Template-Erweiterungen über eigens definierte Twig Templates vornimmt.
OXID eSales ist so nett und stellt bereits einen Smarty to Twig Converter bereit GitHub - OXID-eSales/smarty-to-twig-converter: A Tool to convert smarty template engine to twig template engine
Was aktuell aus eigener Erfahrung noch ungelöst ist - sind die Block Überladungen.
Für den Admin habe ich eine Lösung in Form von einen Workaround gefunden.
Für das Frontend Theme arbeite ich dort mit Twig includes, weil Twig eine mehrdimensionalen Blocküberladung nicht beherrscht und von Seiten OXID eSales mir dort noch keine Lösung bekannt ist.
Eine Möglichkeit wäre dort sicherlich eine Twig Erweiterung, aber bisher wurden anscheinend ausschließlich Smarty Plugins als Twig Erweiterungen in der Twig Component von OXID eSales übernommen GitHub - OXID-eSales/twig-component: Includes twig template engine for OXID eShop
Nein, Du kannst für Frontend und Admin nur komplett auf Twig oder Smarty setzen. Es bedingt beides. Es ist nicht möglich Admin Smarty einzusetzten und Frontend Twig.
Twig Frontend GitHub - OXID-eSales/twig-theme: Templates based on the twig engine
Twig Admin GitHub - OXID-eSales/twig-admin-theme: The admin theme for twig engine
Wäre eine Option, kommt auf die Anzahl der Module drauf an und in wieweit Sie ins Template eingreifen.
Es gibt eine goldene Regel bei OXID: immer 1 Jahr warten, bis man ein major Release oder ein großes neues Feature produktiv nutzen darf.
Ende des Jahres würde ich nochmal gucken, wie viele Bugs es für Twig-Komponente gibt und wie viele Module twig Templates unterstützen.
1 Like
Danke für Eure Antworten, ihr habt mir weitergeholfen. Ich denke auch, abwarten ist die sinnvollste Option und auf twig kann man ja später auch upgraden, wenn die Modulhersteller auch mitmachen.
1 Like
Dies aber nicht so schön für den Community Gedanken, weil bei der Weiterentwicklung profitieren alle Händler*innen von den Features und Bugfixes.
Umso mehr Händler*innen bereits auf die neuste Serie 6.2 updaten und anfangen das Twig Theme zu nutzen umso besser für die Softwarequalität am Ende und umso zügiger die Weiterentwicklung.
1 Like
außer den Händlern, die als unfreiwillige Beta-Tester fungieren und plötzlich Bestellungen und Kunden verlieren, weil in dem 6.0 Release ein komischer DB Rollback drin war, der abgeschloßene und bezahlte Bestellungen wieder gelöscht hatte und die Kunden wochenlang auf Bestellungen warteten, von denen die Händler keine Ahnung hatten.
Oder mit dem neuen WYSIWYG Editor alle Smarty Tags zerstört hatten (Das Problem besteht immernoch).
Oder als der Bug im eingebauten PhpMailer den Quelltext in Emails zerlegte.
Ich sage nicht, dass man komplett die Finger davon lassen sollte, ich sage nur, dass man es nicht sofort produktiv einsetzen sollte, wenn man sich nicht mit solchen komischen Problemen rumschlagen möchte.
1 Like
Der DB Rollback Bug super ärgerlich, aber wenn umso mehr frühzeitig auf 6.0 Release umgestellt hätten, dann stelle ich die Theorie auf das wenn ein aufmerksamer Programmierer oder Händler*innen diesen Bug sehr frühzeitig entdeckt hätte man frühzeitig hätte gegen steuern können.
Dann wäre der Bug wohl ein paar Tage früher gefunden worden, beim Shopbetreiber brennt dennoch der Baum.
Die Lösung steckt m.M.n. nicht in der frühen Implementierung beim Kunden. Man muss sich immer vor Augen halten, dass dort das Geld verdient wird. Da verbrennt jeder Bug echte Euros.
Die Fehler sollten früher gefunden werden. Und das funktioniert nur mit ausreichender Entwicklerdoku, dass die Implementierenden sich vorab drauf einstellen können. Weiterhin muss eine langfristige Roadmap her, dass vor Shoprelease schon die wichtigsten Module portiert sind. Da beißt sich die Katze aber an anderer Stelle in den Schwanz.
Somit muss ich Marat recht geben. Finger weg von X.0-Releases für den Produktiveinsatz. Nicht ohne Grund ignorieren Updatenotifier anderer Projekte (Bsp.: Nextcloud) solche Versionen.
Nehmen wir Best-Case-Szenario an:
Vor LIVE Gang existiert eine Testumgebung des zukünftigen LIVE Shops. Bevor dieser Shop nun auf LIVE geswitched wird werden verschiedene Tests durchgeführt, dazu auch manuelle User-Tests wie z.B. eine echte Bestellung tätigen.
- Wäre Zahlung über Zahlungsanbieter komplett abgeschlossen
- Hätte Shopbetreiber Bestellbestätigung E-Mail bekommen
- Es gäbe die Bestellbestätigung E-Mail des Test-Bestelllers
- Eine Prüfung im Admin hätte ergeben, dass die Bestellung nicht mehr da wäre… nachdem Zahlung abgeschlossen
- Eine zusätzlich angeschlossenes Drittsystem z.B. WAWI hätte Bestellung nicht erhalten
Wenn dies alleine 3 unabhängige Händler*innen tun über Ihre Entwicklungsabteilung, dann sollte so ein Fehler doch bereits vor LIVE Gang auffallen im Best-Case-Szenario zumindest bei einem sollte dies auffallen und dieser könnte als Warn-System für Andere agieren und OXID eSales würde Kenntnis von Bug erlangen, könnte Warnung aussprechen und sich an Bugbehebung machen.
Das untermauert nur meine ursprüngliche Aussage 
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.