Vielleicht kennt ihr die Situation. Ein Kunde fragt an, ob sich ein Shop mit 250 Websites betreiben lässt. Oder ob er seinen Shop problemlos auf 200.000 Produkte hochskalieren kann. Oder ob etwas dagegen spricht, 500 Produktattribute zu verwenden. Oder wie das Menü aussieht, wenn seine neue Navigationshierarchie 10 Ebenen enthält (ok, auf die letzte Idee ist bei mir zum Glück noch niemand gekommen ;)). Oder ihr seid einfach neugierig darauf, einen Test-Store mit Daten zuzuschießen. Echtdaten, die man einfach so einspielen kann, sind natürlich (noch) nicht vorhanden. Willkommen in der Realität.
In solchen Fällen ist es mühsam, immer wieder aufs Neue Skripte zu erstellen, die genau diesen Zweck erfüllen. Als es Anfang des Jahres einen Anlass für einen Datentest gab, dachte ich mir: lass mal eine Extension schreiben, mit der ich über das Backend Testdaten erstellen lassen kann. Und so entstand LimeSoda_SampleDataGenerator.
Den Sample-Data-Generator installieren
Die Extension kann über modman oder composer installiert werden.
Hat alles geklappt, dann findet ihr im Backend einen neuen Menüpunkt "Development > Sample Data Generator" vor.
Navigiert ihr zum Data-Generator, seht ihr zuerst eine leere Übersichtsseite. Mit "Add New" erstellt ihr ein neues Datenset.
Allgemeine Informationen definieren
Im ersten Screen könnt ihr den Datensatz mit einem Namen versehen, über den ihr ihn später auf der Übersichtsseite wiederfindet. Wir basteln im heutigen Beitrag einen "kleinen Webshop".
Auf derselben Seite wird kurz erklärt, wie die gewünschten Datenmengen zu definieren sind. Die Extension geht nämlich davon aus, dass ihr x Websites, Store-Views, Kategorien, Produkte, Attribute, ... mehr generieren wollt. Angenommen in eurer Instanz sind bereits 20.000 Produkte vorhanden und ihr wollt 50.000 darin haben, dann müsst ihr 30.000 eingeben und nicht 50.000. Ok?
Zudem müsst ihr beachten, dass bei verschachtelten Datenstrukturen (Website/Store-Group/Store-View bzw. Kategorien) die Angaben pro Hierarchie-Ebene gelten. Dazu gleich mehr.
Websites, Store-Groups und Store-Views
Eine frische Magento-Installation beinhaltet eine Website, eine Store-Group und eine Store-View. Klar.
Nehmen wir an, dass der Händler neben seinem Hauptgeschäft einen weiteren Shop betreiben möchte, in dem er einen Teil seines Produktsortiments auf Deutsch und Englisch verkaufen möchte. Er benötigt also eine zweite Store-Group mit zwei Store-Views.
Im Screenshot seht ihr das ausgefüllte Formular. Ihr erstellt keine neue Website, denn ihr habt schon eine. Dann legt ihr fest, dass genau eine Store-Group erzeugt werden soll. Mit "minimum count" und "maximum count" könntet ihr eine zufällige Verteilung von Daten erzielen, was vor allem für Kategoriehierarchien, Produkte und Attribute interessant ist.
Die neue Store-Group soll zwei Store-Views erhalten. Auch das ist im Screenshot festgehalten.
Das Märchen von den Angaben pro Hierarchie-Ebene
Nun kommen wir wie versprochen zu den Angaben pro Hierarchie-Ebene. Wenn bei der Store-Group eine 1 eingetragen wird und "Add only to new websites" auf "No" steht, wird für jede Website eine Store-Group eingerichtet. Gäbe es bereits 3 Websites, dann würden 3 Store-Groups angelegt werden: für jede Website eine.
Das klingt am Anfang vielleicht verwirrend. Denken wir uns die Konfiguration aus dem Screenshot durch.
Eine Website habt ihr schon, also braucht ihr keine mehr zu erstellen.
Ihr benötigt genau eine neue Store-Group, also tragt ihr eine 1 ein. Weil ihr keine neue Website erzeugt, müsst ihr festlegen, dass die Store-Groups nicht nur zu neuen Websites hinzugefügt werden, sondern zu allen.
Eure neue Store-Group soll zwei Store-Views enthalten. Damit die originale Store-Group nicht betroffen ist, wählt ihr "Add only to new store groups" mit "Yes" aus. Die ursprüngliche Store-Group 1 bleibt unangetastet, doch für die neue Store-Group werden zwei Store-Views ins Leben gerufen.
Attribut-Sets und Attribute
In den folgenden zwei Tabs ist es möglich, Attribut-Sets und Attribute zu definieren.
Ihr entscheidet euch für insgesamt vier Attribut-Sets, fügt also 3 neue Attribut-Sets hinzu.
Ein kleiner Schönheitsfehler am Rande: in Version 0.1.2 ordnet der Data-Generator alle Produkte dem Default-Attribut-Set hinzu. :-)
Jedes gute Produktsortiment beschreibt seine Produkte über eigene Produktattribute. Unser kleiner Shopbetreiber hat aber vorerst nur wenig Zeit für die Datenpflege, weswegen ihr zwischen 7 und 10 Attributen einplant. Die Attribute werden allen Attribut-Sets zugeordnet.
Kategorien
Der Beispielhändler hat entschieden, sein Sortiment auf 3 Kategorie-Ebenen aufzuteilen. Außerdem hat er von der "7 +/- 2"-Regel gehört und daher 5 Hauptkategorien mit jeweils 4 bis 6 Unterkategorien gebildet. Manche Kategorien zweiter Ebene haben gar keine Unterkategorien, manche bis zu 3.
Produkte
Und jetzt zur Essenz des Shops: den Produkten. Es wird 500 Produkte geben. Außerdem wird jedes Produkt zwischen 1 und 3 Kategorien zugeordnet.
Daten generieren
Nun speichert ihr eurer Datenset und gelangt zurück zur Übersichtsseite.
Indem ihr das Datenset markiert und die Aktion "Generate" ausführt, startet ihr die Generierung der Daten.
Da momentan die normalen Magento-Models verwendet werden und nicht die Import-/Export-Schnittstelle o.ä. kann das bei größeren Datenmengen entsprechend lange dauern.
Zwecks Performance-Optimierung könnt ihr die Caches aktivieren und auf manuelle Indizierung umstellen - genau wie bei jedem anderen Import bringt das erhebliche Leistungssteigerungen mit sich.
Wenn die Daten fertig erzeugt sind, erhaltet ihr eine Übersicht über die neuen Datensätze.
Die erzeugten Daten
So sieht das dann im Backend aus:
Und so im Frontend:
Status und Weiterentwicklung des Sample-Data-Generators
Ich bin mir ziemlich sicher, dass sich der eine oder andere von euch beim Durchlesen dachte: "kann man dieses [Variation X> und jenes [Feature Y> machen"? Die Chance ist hoch, dass die Antwort "nein" lautet. :-D
De facto haben wir den Sample-Data-Generator nur mit dem Allernötigsten verstehen, was für diesen Test gebraucht wurde. Bis heute sind wir damit gut durchgekommen. Für einzelne Tests haben wir die Testdaten (z.B. die Attributwerte, Preise, Sichtbarkeiten, ... der Produkte) verändert, doch zu einem bedienbaren Backend hat es noch nicht gereicht. Ich habe viele viele Ideen, was man noch alles mit der Extension anstellen könnte, doch die fehlende Zeit und der Mangel an Dringlichkeit sind's, welche die Entwicklung entschleunigt haben.
Tatsächlich steht der Code seit vielen Monaten in einem Refactoringzyklus und ich hoffe, diesen durch den Artikel und hoffentlich positives Feedback wieder anzustoßen (ihr kennt das von Runtastic und co - go go go! ;-)).
Momentan hat die Extension mehr einen Prototypen- als einen Beta-Status. Falls jemand von euch in nächster Zeit den Sample-Data-Generator für sich weiterentwickeln und dabei kompatibel mit unserer Version bleiben möchte, dann meldet euch bitte bei mir, denn es wird sich sicher in der Code- und Datenbank-Struktur einiges ändern. Zwei Ziele des Refactorings sind zum Beispiel, dass man die Daten wesentlich flexibler (auch über Events) variieren und andere Importer (z.B. AvS_FastSimpleImport) verwenden kann. Und auch der Ruf nach weiteren Entitäten (Kunden, Bestellungen, ...) ist schon laut geworden.
Ich hoffe, wir können euch mit dem SampleDataGenerator beim nächsten Test etwas Arbeit abnehmen.
