Mein erster Eindruck von Shopware 5

Vor ein paar Wochen haben wir uns in der Agentur entschieden, neben Magento und Magento 2 auch einmal Shopware näher anzusehen. Immerhin sprießen die Shopware-Shops gerade aus dem Boden. Gestern war ich dann auf einem Developer-Training bei Shopware in Schöppingen. In diesem Beitrag möchte ich kurz meine Erfahrungen und erste Eindrücke schildern.

Folgende Themen wurden behandelt:

  • Einführung in die Struktur von Shopware
  • Möglichkeiten Shopware anzupassen (Events & Hooks)
  • Implementierung eines Frontend-Plugins
  • Shopware Models
  • Erweitern eines Backend-Plugins
  • Implementierung eines neuen Backend-Moduls
  • Anpassen von Templates über Blöcke

Folgende Themen standen zwar auf der Agenda, wurden aber nicht behandelt:

  • Debuggen mit Shopware & PHPStorm
  • Bestpractice: Auto-Update eigener Plugins, Mehrsprachenfähigkeit & ACL in eigenen Plugins

Die beiden Trainer Michael Telgmann und Holger-Thomas Kaßner haben einen guten Job gemacht. Immerhin ist es recht schwierig, die ganzen unterschiedlichen Level abzuholen und ohne große Langeweile auf den gleichen Wissensstand zu bringen. Dennoch habe mich etwas unterfordert gefühlt – obwohl ich noch nie Kontakt mit Shopware hatte. Viele Strukturen sind zu Magento 1.x schon sehr ähnlich.

Allerdings sind während des Trainings auch sehr viele Schwächen aufgezeigt worden. Viele Fragen wurden mit „das wird in der nächsten Version behoben“ beantwortet. Im Folgenden möchte ich einmal die Themen nennen, welche mir sauer aufgestoßen sind und meiner Meinung nach in professioneller Software so nicht passieren sollten. Zum Teil konzeptionelle Fehler, andere eher kosmetisch.

Folgendes ist mir sofort aufgefallen, als ich die Datenbank geöffnet habe:

  • Manche Tabellen sind komisch übersetzt. So heißt die Produkt-Tabelle z.B. „s_article“. Hier müsste eigentlich „product“ stehen.
  • Es gibt fast keine Fremdschlüssel in der Datenbank. Es scheint total zufällig zu sein, ob es Fremdschlüssel gibt oder nicht. Manche Tabellen haben welche, andere nicht. Selbst wenn man nicht möchte, dass das Löschen von Datensätzen kaskadiert, könnte man doch wenigstens „ON DELETE SET NULL“ setzen. Fehlende Fremdschlüssel sind für mich ein absolutes NoGo und erzeugen am Ende nur Datenmüll. Ich wette es gibt da draußen irgendwelche Module, welche einem helfen die Datenbank aufzuräumen.
  • Namen von Tabellen und Spalten sind total seltsam. Warum muss man überall einen Prefix davor packen? Falls jemand in eine Datenbank neben Shopware noch etwas anderes installiert, gehört derjenige eh gesteinigt. Aber das ginge ja noch. Viel schlimmer: Es gibt kein einheitliches Namensschema! Mal werden Unterstriche genutzt und eine Tabelle weiter wird dann wieder CamelCase eingesetzt. Gerne auch mit groß ID am Schluss. Wie soll man da bitte den Überblick behalten?
  • Zudem gibt es einen lustigen Sprachenmix. In der Artikel-Tabelle gibt es eine Spalte welche „datum“ heißt. Im Ernst? Klar ist „date“ ein Schlüsselwort in SQL, aber dafür gibt es wirklich Lösungen. Zumal „datum“ auch nicht gerade sehr sprechend ist. Um was für ein Datum handelt es sich denn?

In diesem Beispiel könnte man denken, dass es keine Coding-Standards gibt und jeweils einfach von zwei verschiedenen Entwicklern stammt, welche so arbeiten wie sie es am liebsten mögen.

Weiter geht es mit folgenden Punkten:

Controller – Hier wurde es versäumt, eine entsprechende Modul-Ebene in die Struktur mit aufzunehmen. Baut nun also jemand einen „Info“-Controller (wird zu shop.domain/info), darf dies kein anderer Entwickler mehr tun. Man muss sich also sehr eindeutige Namen ausdenken, auf die wohl am besten kein anderer Entwickler kommt. Da ist Kreativität gefragt. Zudem haben Core-Controller auch sehr wenig sprechende Namen wie zum Beispiel der „Detail-Controller“. Dieser rendert eine Produktdetailseite – würde ich so erstmal nicht drauf kommen.

Lokale Entwicklung – bei der lokalen Entwicklung hat man teilweise wohl das Problem, dass die gekauften Extensions nicht auf den Rechnern laufen. Dann muss man irgendwelche seltsamen Tricks anwenden, sodass die Extensions das nicht mitbekommen. Hier sind so Lösungen mit der etc/hosts im Umlauf – finde ich persönlich eher gruselig.

RAW-SQL im Frontend – ja, es gibt einen Query-Builder. Allerdings habe ich bisher nicht so richtig verstanden, warum hier nicht auch auf Doctrine gesetzt wird. Das Argument war zwar Performance, aber da draußen laufen so viele Symfony-Applikationen, welche alle super mit Doctrine auskommen. Gucke man sich zum Beispiel so eine sExport-Klasse (138 Zeilen SELECT-Statement) an, wird einem schon ein bisschen schlecht und es fühlt sich an wie eine Zeitreise in das Jahr 2000.

Produkt-Importe – Soweit mir bekannt ist, gibt es in Shopware keine Import-Schnittstelle. Möchte man also mehrere 10.000 Produkte importieren, hat man ein Problem. Über Doctrine kann man es wohl vergessen, da es dann viel zu langsam wird. Aber was ist die Alternative? Hoffentlich nicht auch RAW-SQL…

Absolute Pfade in der Datenbank – Als es darum ging, Plugin-Konfigurationen vorzustellen wurde auch eine Bildauswahl vorgestellt. An sich ja sehr praktisch, aber leider wurde der absolute Pfad in die Datenbank gespeichert. Für den Go-Live ist das natürlich extrem nervig. Zudem war der Wert serialized, wodurch man nichtmal mit Search and Replace in der DB arbeiten kann, da dann die Längenangaben meistens nicht mehr stimmen werden.

Smarty – hier kann man sich drüber streiten. Ich hoffe, in zukünftigen Versionen Twig zu sehen. Smarty ist natürlich auch sehr mächtig, aber auch ein wenig in die Jahre gekommen.

Composer – schönes Tool! Nutze ich wirklich gerne. Allerdings frage ich mich, warum man hier nicht auch direkt den Shopware-Core per Composer laden kann. Dann hätte man zumindest kleinere Repos, welche nicht immer den kompletten Core enthalten. Wie es scheint ist dies aber ein Problem, welches auch die Community stört und wo schon der ein oder andere dran arbeitet. Ich finde es nur schade, dass man die Möglichkeiten von Composer nicht voll ausnutzt obwohl man es eh schon im Projekt hat.

Deployment – für mich nach wie vor ein großes Fragezeichen. Als ich Michael darauf angesprochen habe, habe ich die Info bekommen, dass sich da jeder Partner selbst etwas zusammenbastelt. Einen offiziellen Workflow gibt es also irgendwie nicht. Schon blöd. Immerhin ist das für mich ein Teil des Produkts.

ionCube / Marktplatz – viele Extensions im Marktplatz sind verschlüsselt. Diese würde ich z.B. niemals in ein Shop-Projekt aufnehmen. Fremden Code aus unterschiedlichen Quellen einzusammeln ist das eine, aber diesen blind und ohne Code-Review zu vertrauen ist etwas anderes. Zumal mit PHP7 noch mehr Probleme mit dem ionCube-Loader auf einen zukommen. Nein danke – ganz blöde Idee. Also nur die Extension nehmen, welche die Info „Unverschlüsselt“ tragen.

Dokumentation – gibt es zwar und ist auch wirklich umfangreich. Das Problem ist nur, dass man die Doku immer nur für die aktuelle Version sehen kann. Das heißt, dass diese nicht versioniert wird. Könnte ebenfalls ein Problem werden.

gitignore – Danke, dass eine mitgeliefert wird. Ist allerdings total unvollständig. Schon hat man den ganzen Cache im git. Genauso wird wohl kaum jemand alle Produktbilder etc. (media) mit in der Versionskontrolle pflegen. Außerdem sind fast alle Dateien mit CRLF statt nur mit LF. Ändert git von sich aus, also noch zu verkraften. Beweist für mich aber, dass Shopware und Versionskontrolle nicht unbedingt gedacht ist.

Nennt mich verwöhnt, aber in all den Jahren Magento habe mich an gewisse Standards gewöhnt. Shopware 5 ist technisch ungefähr auf dem Stand von Magento 1: Es wird Zeit für etwas Neues. Shopware NEXTGEN ist wohl schon in der Schmiede, allerdings kann aktuell kein Release-Termin genannt werden (nichtmal ein ungefähres Jahr). Auf eine neue Version können wir also noch sehr lange warten. Aber „warten“ kennen wir ja schon von Magento 2 – und das wurde am Ende auch ganz vernünftig.

Das alles sind Punkte, die mir nach nur einem Tag Shopware aufgefallen sind. Den eigenen Entwicklern sind alle diese Themen natürlich ebenfalls ein Dorn im Auge und die Probleme sind bekannt (das wurde mehrfach in der Schulung gesagt). Allerdings ist es natürlich schwer ein Update zu machen, in welchem alles neu ist. Das Problem hat WordPress ja zum Beispiel auch.

Zertifiziert?!

Zusätzlich muss ich nach dem Tag leider sagen, dass ich die Zertifizierungen von Shopware eher fragwürdig finde. Ich meine, ich habe Shopware bis heute nie selbst installiert, noch keine komplette Extension entwickelt. Ich saß nur einen Tag in einem Raum und habe mir Präsentationen angeschaut, welche am Ende mit ein paar Multiple-Choice-Fragen kontrolliert wurden.

Aber hey, nennt mich Certified Shopware Developer

Auf das Zertifikat kann man also nicht besonders stolz sein. Bei Magento gefällt mir dies schon wesentlich besser. Hier kann man die Zertifizierung meiner Meinung nach nur schaffen, wenn man zuvor auch länger mit dem System wirklich gearbeitet hat. Bei Shopware sagt es für mich gerade nur aus, dass man das Geld für ein Training ausgegeben hat.

Natürlich weiß ich nun, wie die Ordner-Strukturen aufgebaut sind und was man so machen könnte. Aber so komplett ohne Praxis jetzt damit zu werben fühlt sich falsch an. Gerade das Thema Backend mit ExtJS bedarf noch einiges an Einarbeitungszeit.

Fazit

  • Shopware ist für mich nicht besonders „Enterprisy“, sondern eher ein „lad mich per FTP hoch und installiere alle Plugins über das Backend direkt auf dem Live-System“-Framework. Das beweisen zumindest viele fehlende Konzepte für verteiltes Arbeiten.
  • Die Zertifizierungen sind kein Qualitätsmerkmal und helfen nicht bei der Auswahl der Agentur
  • Shopware positioniert sich dafür für mich irgendwo zwischen WooCommerce und Magento
  • Das Team, die Location und das Marketing rund um Shopware funktioniert super – immerhin hat man einen Ansprechpartner in greifbarer Nähe und muss sich mit seinem Problem nicht ganz alleine rumschlagen

Ich bin auf das gespannt, was in den nächsten Jahren noch passiert. Was Shopware gut kann ist Marketing – zumindest sind sie in aller Munde. Und einem Geschäftsführer verkauft man ja auch keine Code-Qualität. Von außen sieht erstmal ja auch alles toll aus.

Über

Jahrgang 87, gelernter Softwareentwickler und 15 Jahr Erfahrung im Bereich Web-Entwicklung mit PHP. Weiterhin bin ich seit Ende 2013 Magento Certified Developer.

7 Kommentare


    • Hi Nick, schwer zu sagen – wahrscheinlich wenn ich einen kleineren Shop bauen würde, welche nur Produkte über das Backend pflegen möchten und viel selber zusammenklicken möchten ohne viel Customizing.

  • Hallo,

    ich selbst bin Shopware Entwickler und muss bei manchen Punkten sagen: ja, du hast Recht, vor allem bei Tabellen Benennungen aber manchmal kann man dahinter kommen, was sich die Jungs gedacht haben. Shopware kommt aus Deutschland, dies erklärt einige der Benennungen (wie z.b. s_article anstelle s_product weil es in Shopware ein „Artikel“ ist und kein „Produkt“).

    Allerdings muss ich bei einem Punkt vehement widersprechen: Produkt-Importe
    Es gibt das Shopware Import/Export Advanced Module. Über dieses ist es möglich via TableField Mapping sowohl XML, als auch CSV zu importieren. Sogar mit über 100.000 Produkten (unser Rekord war eine CSV mit 1,6 GB):
    http://store.shopware.com/swagef36a3f0ee25/shopware-import/export.html

    Shopware kommt auch out of the box mit Elastic Search Unterstützung. Macht allerdings nur sinn bei mehr als 100.000 Artikeln. Ansonsten läuft Shopware extrem schnell, ohne andere Tools, wie Vagrant vorzuschalten.

    Mehr Symphony, weniger Enlight und dazu Twig wird mit dem nächsten größeren Shopware (evtl. Shopware 6) kommen.

    Grüße

    Andi

    • Danke für dein Feedback – ich würde mich sehr freuen, wenn Du mit deiner Erfahrung auch etwas zu git-Workflows, gekauften Extensions in der lokalen Entwicklungsumgebung, Staging-Live, Deployment und den anderen Punkten sagst. Mit mySQL-Benennungen könnte ich noch am ehesten leben von den genannten.

      Das Import/Export-Tool macht einen guten Eindruck auf den ersten Blick (habe den Source nicht angeschaut).

      Shopware läuft schnell, das ist richtig. Aber wenn man RAW-SQL im Frontend verwendet, welches nur schwer erweiterbar ist, dann ist das auch nicht so super schwer. Da kommt es darauf an wie man den Fokus legt. Bei Magento 2 ist z.B. alles extrem entkoppelt und dadurch super langsam während der Entwicklung – ein Mittelweg wäre schön.

      Cool ist eigentlich auch, dass der Shopware-Core kaum Funktionen mitbringt. Das macht es natürlich wenig überladen und es wird sich auf das wesentliche fokussiert.

      Ein weiterer Punkt ist die relativ kleine Shopware-Community. 146 Contributors auf GitHub sind nicht wirklich viel – und auch auf Stackoverflow etc. werden kaum Fragen gestellt / beantwortet (258 Treffer). Das zeigt mir eigentlich, dass die Community nicht besonders groß ist. Immerhin ist es laut Wikipedia 4 Jahre älter als Magento (91.213 Suchtreffer bei Stackoverflow + eigene Seite).

      Ich freue mich jedenfalls auf die nächste Version wenn das alles rausfliegt. Ich wünsche mir, dass man sich bei Shopware traut, all das rauszuwerfen was aktuell nicht zu Ende konzipiert ist und dabei keine Rücksicht auf Kompatibilität auf aktuelle Extensions nimmt. Nur so kommt man sicherlich aus der aktuellen Situation sauber raus.

  • Wir entwickeln Lokal mit Docker und haben durch eine Shopware Partnerschaft eine Wildcard Domain auf unsere Dev-Umgebungen, die wir sowohl Lokal, als Dev-Server und Staging-Server verwenden. Somit können wir die Lizenzen im Showpare Store als „Test-Lizenz“ kaufen auf diese Domain und dadurch auch testen. Wenn wir Probleme mit Lizenzen haben, rufen wir bei Shopware an und die helfen uns immer und vor allem schnell.

    Wir haben eigentlich intern den „standard“ git-workflow, allerdings haben wir nicht die komplette Shopware Source im Git, sondern nur die Bereiche, die wir auch wirklich anfassen. Der rest ist innerhalb der Docker-Box vorhanden und wir mounten nur die Folder, die wir auch anfassen. Deployment läuft über GitlabCI und wir ziehen uns während dem Deploy die gewünschte Git-Version und spielen da unsere Änderungen drauf. Somit können wir auch schnell Updaten.

    Shopware verwenden an vielen stellen Raw-SQL mit PDO, das stimmt, hat aber auch oft sogenannte Filter Hooks, über die man die Queries anpassen kann. Warum sie hier nicht komplett auf Doctrine gegangen sind, ist mir ebenfalls ein Rätsel. Ich hoffe, sie werfen das auch über Board mit Shopware 6 😀

    Die Backend-Extension Entwicklung in Magento (1, mit 2 habe ich keine Erfahrung) ist viel einfacher als in Shopware, weil dies derzeit via ExtJS realsiert ist, was für viele, und auch für mich, ein sehr großer Dorn im Auge ist. Dies soll aber in der nächsten Größeren Version komplett entfernt werden und dafür dann über Web-Components funktionieren.

    Ioncube: ja, sehr doof. Shopware will davon aber nun weg und hat angefangen seine eigenen Plugins nicht mehr zu verschlüsseln. Einige Entwickler machen es Shopware nun gleich und bieten unverschlüsselte Plugins im Shop an, nur halt leider nicht alle.

    • Das mit den Wildcard-Domains klingt ja wirklich nach einer guten Lösung. Ich frage mich allerdings, warum das auf Nachfrage in den Trainings nicht auch so vorgeschlagen wird… Scheint ja nicht so, als wäre das für Euch eine totale Ausnahmeregelung?!

      Welchen Standard-git-workflow? Dazu habe ich nichts in der Dokumentation gefunden – hättest Du dazu einen Link? Genauso würde ich mich über ein paar Links zum Docker-Workflow freuen. Schreibt ihr dazu Blogbeiträge o.ä.? Das ist ja genau das was ich meine – ich suche solche Themen und kaum jemand publiziert etwas dazu. Die Community scheint da sehr verschlossen zu sein und jeder werkelt vor sich hin.

      ExtJS finde ich auch nicht besonders schön – aber wenn man sich daran gewöhnt, kann man sicher damit leben. Das wäre für mich kein Ausschlusskriterium.

      Auch was Du so schreibst lohnt sich gefühlt das Warten auf die neue Version (welche ja dann eh wieder alles anders macht). Ansonsten würden wir ja praktisch 4 Shopsysteme betreuen (Magento 1, Magento 2, Shopware 5, Shopware 6?). Das wäre dann ja doch ziemlich viel auf einmal für eine kleine Agentur. Außer dem Namen hätten die jeweiligen Versionssprünge ja dann nichts mehr gemein.

  • Das ist unsere Docker Box:
    https://hub.docker.com/r/1drop/shopware-52/

    Blog Einträge haben wir hierfür gar keine. Werde ich aber in Zukunft machen, wenn mein Blog mal steht 🙂

    Intern verwenden wir wohl einen anderen Git-Workflow als es Shopware tut, was ja kein Problem sein sollte. Wir verwenden ein ähnliches System wie dieses: http://blog.endpoint.com/2014/05/git-workflows-that-work.html nur das wir die Feauter Branches vom Master erstellen, anstelle vom Develop Branch.

Kommentar verfassen