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.

CREATE TABLE `s_articles_categories_seo` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `shop_id` int(11) NOT NULL,
  `article_id` int(11) NOT NULL,
  `category_id` int(11) NOT NULL,
  PRIMARY KEY (`id`),
  KEY `shop_article` (`shop_id`,`article_id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

#vs.

CREATE TABLE `s_articles_categories_ro` (
  `id` int(11) unsigned NOT NULL AUTO_INCREMENT,
  `articleID` int(11) unsigned NOT NULL,
  `categoryID` int(11) unsigned NOT NULL,
  `parentCategoryID` int(11) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `articleID` (`articleID`,`categoryID`,`parentCategoryID`),
  KEY `categoryID` (`categoryID`),
  KEY `articleID_2` (`articleID`),
  KEY `categoryID_2` (`categoryID`,`parentCategoryID`),
  KEY `category_id_by_article_id` (`articleID`,`id`),
  KEY `elastic_search` (`categoryID`,`articleID`)
) ENGINE=InnoDB AUTO_INCREMENT=740 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;

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.