Eine große Schwäche vom Original ist, dass die Shop-Theme Auswahl sehr stark eingeschränkt.
Dort wäre es toll wenn es gelingt, dass das Shop-Theme mehr von der Logik zu entkoppeln und eine Anleitung zur Verfügung zu stellen wie man sein eigenes Shop-Theme technisch umsetzen kann.
Mit der Zielsetzung dort mehr Vielfalt anbieten zu können.
Das wäre natürlich gut. Hast Du ein Beispiel, wie Du Dir die Entkopplung technisch vorstellst?
Hmm… man könnte in mehreren Stufen vorgehen:
3a. Man könnte überlegen dies gleich zu nutzen um auf Twig Engine umzusteigen und die vorgeschlagene Namenskonvention zu übernehmen Creating and Using Templates (Symfony Docs)
3b. Alternativ wäre auch denkbar statt Template Engine auf PHP Dateien umzusteigen um Einsteigern die Arbeit leichter zu machen, indem nicht eine Template Engine lernen müssen Templating (Symfony Docs)
Die Dokumentation wie man ein Shop-Theme erstellt sollte dabei gut gepflegt werden, um eine zentrale Anlaufstelle zu haben wie einzelne Template Bestandteile strukturiert und Dinge miteinander zusammen hängen.
Die Hoffnung wäre mit einer guten Theme Dokumentation mehr Personen in die Lage zu versetzen eigene individuelle Shop-Themes erstellen zu können.
Ich kenne keinen einzigen OXID Shop, ausser vielleicht einige High End Shops, die ein eigenes Template entwickelt haben.
Dies ein Kernproblem. 98% der Shop-Themes basieren auf einem Standard Theme wie Azure, Flow oder Wave. Die JavaScript Abhängigkeiten und Template Namenskonventionen inkl. fehlende Theme Dokumentation wie man eigenes Theme angelegt sorgen dafür, dass man sich immer an Standard Themes orientiert.
Hinzu kommt, dass die tiefe Verschachtelung der Theme Verzeichnisstruktur den Aufwand für die Einpflege eines individuellen Themes zeitlich sehr erhöht. Ein individuelles Theme kostet ungefähr 100 Stunden und mehr an Aufwand.
Auch ich sehe die Priorität für ein verbessertes Frontend-Theme absolut hoch und stimme zu, dass mit Abstand die meisten unserer Shops wohl nicht ein vollständig eigenständiges Theme entwickeln werden.
Als wichtig betrachte ich:
Konkret würde mich eure Meinung zum OXID Moga-Theme interessieren. Könnte mir das u.U. als eine Art Basis vorstellen.
Stimme zu der Kernaussage zu.
Aber würde mich nicht auf ein Frontend Framework wie Bootstrap, React, Vue, Tailwind etc. festlegen wollen. Das Ziel sollte sein, dass ein Shop-Theme Frontend Framework unabhängig erstellt werden kann.
Bei den Zahlungsarten im Checkout häufig das Problem, dass sich an HTML-Struktur und JavaScript Logik orientiert wird damit eine Zahlungsart funktioniert.
Die Abhängigkeit gilt es zu vermeiden und den Zahlungsdienstanbieter/Modulanbieter dazu zu zwingen eine bessere Integrationsanleitung mit auszuliefern, welche Frontend Anpassungen vorgenommen werden müssen damit ein Modul seine Aufgabe erfüllen kann.
Das Moga-Theme hat gegenüber Flow und Wave den Vorteil, dass die Bootstrap Version erneuert. Weitere Vorteile sehe ich dort nicht.
Könnte hier die REST/GraphQL API helfen? Dann kann man den Konsumenten als Bibliothek bauen (Composer, React, Angular, …) und das Frontend kann mit dem Framework der Wahl gebaut werden.
Der Smarty/Twig Teil könnte evtl. zukünftig sogar aus dem Core entfernt werden.
Das könnte mittelfristig ein Plan sein. Behalte den Gedanken mal bei.
Dort ist das Original mit seinen GraphQL Modulen bereits voraus geeilt, auch wenn es noch nicht perfekt ist - aber man kann zur ersten Version bereits eine Besserung erkennen.
Kernproblem mit GraphQL und Vue/React ist die hohe Einstiegshürde für Programmierer*innen und die Fehleranfälligkeit. Wenn Du auf dem Seitentyp Detailseite einen Fehler einbaust, dann funzt ganzer Shop nicht mehr. Fachkräftemangel lässt grüßen.
Eine REST API könnte für Warenkörbe eine hohe Speicherlast erfordern und ein Shop kann über DDoS Attacken leichter in die Knie gezwungen werden, weil Du dann den Warenkorb immer in der Datenbank vorhalten musst. Beim klassischen Shopsystem, merkst Dir solange der Benutzer nicht eingeloggt, den Warenkorb in den Cookies.
Gegen Smarty spricht, dass man sich als PHP Framework für Symfony entschieden hat was auf Twig ausgelegt ist und damit besser harmoniert.
Der größte Vorteil einer Template Engine in der Regel das integrierte Caching, was aber bezüglich Twig Template Engine beim OXID noch ein Problem ist. Das Caching von Smarty funktioniert besser als Twig, dies mein Erfahrungswert aus einer Umstellung. Bisheriger Workaround ein Prozess welcher Twig Cache vom OXID regelmäßig leert.
Wenn man Zusammenhang zwischen Theme und Shop Funktionalitäten betrachtet, ist wichtigster Part eines Shopsystem die Warenkorb Logik welche mit dem Theme harmonieren muss.
Beim OXID sind die Abhängigkeiten zwischen Theme und Shop leider größer, z.B. die Varianten auf der Produktdetailseite, Checkout sehr JavaScript lastig ein Hin- und Herspringen über Browser Vor- und Zurücktaste gar nicht möglich etc. oder die Hauptnavigation orientiert sich an der Kategoriestruktur.
Es werden einerseits für das Theme sehr viele technische Entscheidungen einen abgenommen, andererseits ist dies auch die große Schwäche weil man sich an diese technischen Entscheidungen orientieren muss oder man schreibt eine Lösung die um das OXID Framework herum gebaut ist. Was wiederum die Unterhaltungskosten in die Höhe treibt für den Händler * in.
Dies auch einer der Kerngründe warum ich mir größeren technischen Schnitt bei O3 Shop gewünscht hätte. Man hätte sich mehr abstrakt angucken sollen welche technischen Entscheidungen aufgelöst bzw. ersetzt werden sollten, anstatt sich in kleinen Details zu verlieren.
Ich denke, das primäre Ziel war es, den Händlern, Entwicklern und Agenturen eine rechtl. unproblematische und weiterhin kostenfreie Alternative zu bieten die zudem keinen oder sehr wenig Migrationsaufwand bedeutet. Ich würde sagen: Mission accomplished und Congrats 
Es dürfe auch gerne noch Features ergänzt werden, die einen Umstieg von der PE/EE ermöglichen
Ich hoffe, die 1.x wird als LTS so lange wie möglich erhalten und aktualisiert.
Für eine 2.x würde ich mir wünschen, wie gesagt, dass der O3 auf Headless setzt und den Entwicklern und Agenturen die benötigten Werkzeuge (und einen Migrationspfad) an die Hand gibt.
Dann haben Entwickler und Agenturen m.E. wirklich die freie Wahl was die Frontend-Technologie angeht - was nicht heißt, dass der Shop kein Template (das die API oder die doch beibehaltene Template Engine nutzt) mitliefern darf. Das führt auch dazu, dass die Gruppe der Entwickler und Agenturen, die auf O3 als Shopsystem setzen können, wesentlich größer wird, was dann auch der Verbereitung des O3 helfen könnte.
Evtl. kann man auch einen Open-Shopping-API-Standard definieren, den auch andere Systeme implementieren können? Gibt es sowas vielleicht schon?
Ist vielleicht ein bisschen (zu) groß gedacht, aber meiner Meinung nach ist Headless der beste Weg Frontend und Logik voneinander zu entkoppeln und für mich der way to go.
@Axel insgesamt gute Gedanken und ein optimistischer Ausblick.
Dies wird mit Symfony Components Versionen 3.4.x composer.json · dev_b-1.2 · O3 Gitlab / shop-ce · GitLab nicht gelingen.
Da diese bereits seit 2021 nicht mehr supported werden. Willkommen im Jahr 2023.
Man ist bereits gezwungen die WayBack Maschine zu konsultieren um dies zu sehen https://web.archive.org/web/20210116023307/https://symfony.com/releases
Ouelle: Symfony Releases vom 16. Januar 2021
Ja, mit Sicherheit gibt es bereits einen API-Ansatz mit der Einschränkung kommerzieller Art.
Dies würde wieder vom Monolith Gedanken abweichen, was einer der Hauptgründe sein mag warum man sich damals für OXID als Lösung entschieden hat.
Headless würde dafür sprechen von Vorne anzufangen oder zu wechseln.
Der Umstieg auf ein anderes zukunftsfähiges Shopsystem tut einmalig weh, aber wahrscheinlich die bessere Wahl.
