wir refactoren gerade unseren Shop, der in die Jahre gekommen ist.
Aus mehreren Gründen haben wir uns entschieden, ein komplett eigenes Theme auszuarbeiten.
Nun haben wir eine ganze Reihe von Modulen, die lediglich dem Theme zuarbeiten, z.B. API-Request mit JSON-Aufbereitung usw.
Ich finde es naheliegender, für solche Aufgaben nicht extra eigene Module zu nutzen und habe daher angefangen, sowas auf Plugin-Funktionen umzuschreiben, wo es sinnvoll ist. Laut KGrind-Profiler verbessert das auch die Performance etwas.
Vorerst habe ich die Smarty-Plugins in source/plugins abgelegt, da das (wohl defaultmäßig) sowieso als Plugin-Location registriert ist.
Da die Plugins themespezifisch sind und auch Theme-Variablen damit verbunden sind, würde ich die Plugins aber lieber direkt mit in unser Theme-Package packen.
Die Metadatei für Themes (theme.php) scheint wohl kein Plugin support anzubieten (sowas wie ‘SmartyPluginDirectories’ bei Modulen) - zumindest konnte ich nichts in die Richtung finden.
Natürlich funktioniert das Ganze auch so, solange niemand Dummheiten begeht.
Eleganter wäre es natürlich dennoch, themespezifische Plugins auch wirklich in das Theme zu integrieren.
Hat hier jemand vielleicht eine Idee, wie man das sinnvollerweise Angehen könnte?
langfristig fliegt Smarty aus dem OXID Framework raus und damit verbunden auch Smarty Plugins. Daher wäre es von der Strategie vielleicht sinnvoller auf die GraphQL Module von OXID eSales aufzusetzen.
Aber dies aktuell eine schwierige Entscheidung, worauf man setzen sollte. Ggfs. die nächsten Releases für 6.5er Serie und den zweiten Release Candidate für die 7er Serie abwarten. Dann weiß man mehr wielange Smarty noch unterstützt oder ob ab der 7er raus ist…
Generell die Tatsache das Module dem Theme zuarbeiten gar nicht so unüblich. Jetzt wäre es sicherlich Geschmackssache ob man ein großes Modul was dem Theme zuarbeitet umsetzt oder viele verteilte Module (wie bisher bei Euch).
Aber ob dies Performance Vorteile bringt wie Smarty Plugins müsste man prüfen bzw. ob man die Smarty Plugins gezielt in die Component effizient unterbringen kann.
Sollte der “gefundene Weg” mit source/plugins Verzeichnis für Euch funktionieren, warum davon abrücken?
Andererseits falls sich die Art der Theme Umsetzung mit direkter Verknüpfung von Smarty Plugins für Euch bewährt, wäre ein Einsatz dem Shop über ein Modul beizubringen die Smarty Plugins im Theme Verzeichnis zu suchen…
OXID eSales selber scheint dort mehr auf GraphQL als Schnittstelle fürs Frontend zu setzen als neue Standard Themes oder eine Best Practise zu veröffentlichen was das Anlegen von Themes anbelangt.
Oh, das Smarty komplett rausfliegen soll, war mir gar nicht bewusst. Vielen Dank für die Info!
Habe im Source vom Core gesehen, dass man da scheinbar auf etwas hinarbeitet (RendererBridge usw), aber dachte eher an sowas wie Auswahlmöglichkeiten zwischen Smarty/Twig o.ä. als Template-Engine.
Fände es persönlich sehr schade, wenn OXID diesen Weg geht. Wir sind sicher nicht die einzigsten, die ihren Shop dann komplett neu ausarbeiten müssten, um updatefähig zu bleiben und an für sich ist Smarty ja schon eine feine Sache (verwende das 3er auch in einem privaten MVC-Projekt und bin da auch sehr zufrieden damit)
Das sich OpenQL so breit einsetzen lässt, wusste ich gar nicht. Bin aber auch nicht allzu vertraut damit - vermeide BigTech-Erzeugnisse so gut es geht.
Eine gebündelte Component wäre natürlich auch eine Idee, vermute aber auch, dass das Kosten/Nutzen-Verhältnis da eher auf der Seite vom bisherigen Lösungsansatz liegt.
Ich klinke mich kurz mit ein, da ich das Thema immer wieder interessant finde @stuck1a: Trau Dich und stelle neben Deinem Child-Theme auch ein kleines projektspezifisches Modul bereit, indem Du dort Deine Smarty-Functions und -Modifiers platzierst (via smartyPluginDirectories). Meist existiert sowieso schon ein projektspezifisches Modul und da passen die Smarty-Functions perfekt rein. Also projektspezifische Smarty-Tags in einem Projekt-Modul für ein Projekt-Child-Theme. Das klingt nach unkomplizierter Lösung. Das Modul und das Childtheme überleben dann jedes Composer-Update
tatsächlich ist das Theme technisch gesehen (noch) ein Child vom Azure-Theme, de facto weichen allerdings 80% der Templates so stark davon ab (unser Grafiker war sehr kreativ bei der grafischen Ausarbeitung des neuen Shops g), so dass die Fallbacks dahingehend relativ nutzlos sind, weshalb ich das bei Gelegenheit auch noch entkoppeln werde. Dazu kommt, dass ich aus performancegründen zahlreiche Funktionen rausgeworfen habe, die wir absolut nicht benötigen (andere aber vielleicht schon).
Als Programmierer aus Leidenschaft würde ich das natürlich gerne releasen, muss das aber erstmal mit meinem Chef abklären (ich bin nur der Lead Programmer ) und dann vermutlich auch einiges rausnehmen. Ein ready2use-Theme wie RoxIVE wäre das daher sowieso nicht.
Natürlich wäre das sicherlich für den ein oder anderen Entwickler sehr interessant und hilfreich. Ich erinner mich zu gut, wie schwerfällig ich mich vor ca. einem Jahr in OXID reinwuseln musste, als der alte Lead unerwartet ging. Zusammen mit über viele Jahre hinweg verwachsenen Lösungen (ich nenne es gerne unseren “Abhängigkeits-Achter” ) und der minimalistischen Doku war das echt nicht allzu angenehm.
Wenn es soweit ist, werde ich trotzdem mal versuchen, den Segen dafür zu kriegen.
Das Theme befindet sich aktuell aber noch Bearbeitung und weißt auch noch einige Großbaustellen auf. Userbereich, ein Großteil des Checkout-Prozesses, diverse Marketplace-Integrationen, die Doku für den Nachwuchs und einige ergänzende und firmenspezifische Funktionen wie der Artikel-Konfigurator (Computershop) sind noch halbroh bis abstrakt und am Ende muss das gesamte Teil definitiv auch intensiv refactored werden, d.h. bis dahin wird noch einiges an Wasser den Berg hinab fließen.
Werde aber definitiv noch die ein oder andere Plugin-Funktion in der Forge hochladen, sobald ich Zeit dafür finde. Kann mir bei dem ein oder anderen durchaus vorstellen, dass wir da nicht die ersten/letzten sind, die die Funktionalität gebrauchen können. Zumindest, solange Smarty unter OXID noch nicht EOL ist
) und der minimalistischen Doku war das echt nicht allzu angenehm.