Warum man auch mal auf Magento-Module von Drittanbietern verzichten sollte oder "Ein Modul zum Preis von zweien - Erlebnisse in Magento-Projekten"
Die Überschrift verrät es schon: Dies ist kein Loblied auf das weitläufige Angebot von Magento-Modulen. Die Extensions von Dritten gehören für Magento-Entwickler zum Arbeitsalltag dazu, denn wünscht der Kunde z.B. ein Zahlungsmodul oder eine Anbindung an externe Dienstleister, übersteigt der Aufwand für die Individualentwicklung regelmäßig die Grenzen des für den Shop-Betreiber finanziell machbaren und sinnvollen Rahmens. Als Magento-Entwickler lernt man also, bei Anforderungen im eigenen Erfahrungsschatz, dem anderer erfahrener Magento-Entwickler und letztlich auch Magento Connect zu kramen, immer auf der Suche nach der bestmöglichen Lösung, die alle wesentlichen Anforderungen abdeckt, ohne zu viele sinnlose Code-Zeilen miteinzuschleppen - und das alles zu einem günstigen Preis, unverschlüsselt, ohne Sicherheitslücken.Hat man diese eierlegende Wollmilchsau gefunden, folgt ein Hipp-Hipp-Hurra! Auch wir haben vor kurzem eines dieser Objekte für Magento gefunden. Doch aus dem Hipp-Hipp-Hurra wurde bald ein Hipp-Hipp-Aua. Beginnen wir am Anfang der Geschichte:
Phase 1: Anforderung
Eine Anforderung eines Magento 1-B2B-Projektes lautete wie folgt:
Kunden sollen pro Produkt individuelle Preise erhalten.
Dies klingt nach einer einfachen Anforderung. Magento beherrscht dies auf Basis von Kundengruppen, allerdings nicht für einzelne Kunden. Die erste Idee, für jeden Kunden eine eigene Kundengruppe anzulegen, scheidet aus, da die Magento-Indizes nicht auf mehrere tausend Kundengruppen ausgelegt sind. Was folgte, war eine Marktanalyse: Eine solche Funktionalität wird sicherlich häufiger benötigt, also wird es dazu vernünftige Module geben. Wir haben auch tatsächlich ein Modul gefunden, das auch nach dem Code-Review einen vernünftigen Eindruck machte. Der Kunde war gern bereit, dafür einen mittleren dreistelligen Betrag zu bezahlen. Das Modul bot neben der eigentlich gewünschten Funktionalität noch einige Funktionen mehr, die wir nicht nutzten.
Phase 2: Probleme
Während der länger dauernden Entwicklungs- und Testphase des Moduls hatten wir keine Probleme. Als kurz vor dem Launch des Shops allerdings sämtliche Kunden- und Preisdaten importiert wurden, begannen die Probleme:
- Produktseiten im Adminbereich ließen sich nicht mehr laden, da mehrere tausend Zeilen (eine pro Kunde) per JavaScript gerendert wurden
- Das gleiche galt für Kundenseiten im Adminbereich - dort lagen jeweils mehrere tausend Preise für verschiedene Produkte vor
- Der Kundenimport verzögerte sich deutlich und benötigte mehrere Sekunden pro Kunde, da das Modul beim Laden eines bestehenden Kunden immer sämtliche Produktpreise mitgeladen hat
Wir haben zunächst begonnen, die Probleme einzeln zu beheben, indem wir z.B. Observer beim Import deaktivierten oder die Anzeige der Kundenpreise aus der Backend-Ansicht entfernten. Mit fortschreitendem Projektverlauf wurde aber eine Erkenntnis immer klarer: Mit diesem Modul können wir nicht dauerhaft arbeiten.
Phase 3: Lösung
Um die Performance-Probleme zu beheben, musste das Modul ausgetauscht werden. Aus Schaden klug geworden, beschlossen wir, ein eigenes, projektspezifisches Modul zu entwickeln. Dieses musste die folgenden Anforderung erfüllen:
- Neue Datenbank-Tabelle, um Preise pro Kunde und Produkt aufzunehmen
- Verwenden der gespeicherten Preise im Frontend
- Darstellung der Kundenpreise im Magento-Adminbereich
Im Endeffekt hat die Umsetzung des Moduls weniger als zwei Personentage in Anspruch genommen; einen Großteil davon benötigten wir dafür, um Performance und die Richtigkeit der Daten optimal zu verknüpfen: Jeder Preis sollte nur einmal pro Kunden abgefragt und ansonsten in der Session vorgehalten werden, während gleichzeitig auch die Invalidierung durch einen Preisimport berücksichtigt wurde.
Lehrgeld gab es genug
Im Nachhinein haben wir erkannt, dass wir von Anfang an ein individuelles Modul hätten bauen sollen. Dies hat gegenüber dem Kaufmodul mehrere Vorteile:
- Es ist genau auf die Projekt-Anforderungen abgestimmt
- Es gibt keine unerwarteten Konflikte mit anderen (Kauf-)Modulen
- Es werden keine nicht benötigten Funktionen integriert, die vor allem mögliche Fehlerquellen sind und Kaufmodule häufig unnötig aufblähen
Was kann man allgemein aus unserer Odyssee lernen?
- Die Anforderungen des Kunden sollte man ganz genau analysieren und verstehen. Das heißt auch wissen, was der Kunde nicht will.
- Manche potenziellen Fehlerquellen basierend auf den Anforderungen bzgl. Skalierbarkeit, Performance und Sicherheit kann man hervorsehen. Hier bietet es sich an, ein bisschen Optimist vs. Pessimist mit den Kollegen spielen - was könnte alles schiefgehen?
- Aufwand für die Eigenentwicklung abschätzen - lohnt sich das Kaufmodul mit zeitlichem Aufwand für Code Review wirklich? Mit diesem Wissen kann man während des Modulauswahl- und Deployment-Prozesses deutlich besser informierte Entscheidungen treffen.
Für Drittanbieter sind fremde Magento-Systeme wie eine Blackbox. Skalierbarkeit und Performance eines Kaufmoduls können nicht für jede Shop-Größe getestet werden. Hier ist also eine gewisse Skepsis ratsam. Leider ist für technisch weniger versierte Shopbetreiber und Projektverantwortliche nicht so leicht verständlich, weshalb die Integration eines Moduls (sprich: Auswahl, Code Review, Installation, Test) in manchen Fällen so viel Aufwand bedeutet.
Als Anbieter für Magento-Module wissen wir, dass der Einsatz von Kaufmodulen ein Kompromiss ist zwischen Anforderungen und Budget. Nicht ohne Grund gilt bei manchen großen Magento-Agenturen die Regel: "Keine fremden Module!" Wir werden weiterhin auf Kaufmodule setzen, wenn es sinnvoll ist, das heißt bei Anforderungen, die in der Individualentwicklung ein Vielfaches des Kaufmoduls kosten.