– ganz so einfach ist es nicht. Wenn man sich allerdings an eine Grundanleitung hält, kommt man schnell zum Ziel.

• Konfiguration
• Angebot/Listing erstellen
• Produkt-Upload auf Ebay

Konfiguration für Ebay

Konfiguration und Connection zum Ebay-account

Als erstes übernimmt M2E die Daten aus Magento. Wenn alle Angaben korrekt sind können diese bestätigt werden und sind übernommen. Über Production-Live-Envoirment gelangt man dann zu einer Eingabemaske in der man sich mit Ihrem Ebay-Account. Unter Umständen sind noch weiteren Angaben nötig.

Wie auch empfohlen, wählt man zunächst den “simple mode“. Im Nachhinein kann noch auf den M2E Pro Mode gewechselt werden.

M2E sollte jetzt mit dem Ebay-account verbunden sein.

Angebot/Listing erstellen für Ebay

Sie klicken in Ihrem Backend-Menu auf den Reiter “Ebay“ und wählen den Punkt “Angebote“. Drücken Sie auf “Angeot hinzufügen“. Es öffnet sich nun eine neue Seite mit drei Punkten zu verschiedenen Einstellungen. Diese Einstellungen sind eher Ebay-spezifisch und dem entsprechend sehr individuell. Sie füllen also alles genau so aus wie es für Ihren Bedarf notwendig ist.

Nach dem Bestätigen der Einstellungen kommen Sie zur Auswahl Ihrer Produkte für das Listing. Sie können die Produkte aus der Produktliste oder aus der Kategorieliste wählen. Drücken Sie auf “weiter“ und wählen die Produkte die Sie in Ihrem Listing haben möchten.

Im nächsten Fenster können Sie aussuchen ob Sie die ausgewählten alle in die gleiche Ebaykategorie einfügen möchten oder in verschiedene. Jenach bedarf wählen Sie hier und gelangen dann zur Auswahl der Kategorien.

Auf den folgenden Seiten fügt man verschiedene Merkmale für die Produkte hinzu. Diese sind auch wieder Individueller Art und ist nach Bedarf auszufüllen.

Sie haben nun alles ausgewählten Produkte in Ihr Listing hinzugefügt.

Produkt-Upload auf Ebay

Sie klicken in Ihrem Backend-Menu auf den Reiter “Ebay“ und wählen den Punkt “Angebote“. Alle Voreinstellungen für den Upload auf Ebay haben Sie schon im Listing konfiguriert. Drücken Sie nun auf das Listing in der Tabelle um die Seite mit allen im Listing enthaltenden Produkten zu sehen. Sie können nun einzelne Produkte auswählen oder alle auf einmal um Sie hochzuladen. Nach Ihrer Auswahl wählen sie im oberen Teil der Tabelle  im Drop-Down-Menu den Punkt “Artikel bei Ebay einstellen“ und drücken “absenden“.

Es erscheint ein Ladebalken und eine Success-Message. Sie haben nun Ihre ersten Produkte auf Ebay hochgeladen.

 Führen Sie diesen aus nach dem Sie in den Ordner Ihres Magentorojektes gewechselt haben.

Der Beitrag M2E Pro – Konfiguration in Magento 1.9 für EBAY erschien zuerst auf Entwicklungshilfe NRW.

Konfiguration für Amazon

1) Lizenz einrichten

Bei Erstaufruf des „Amazon“-Reiter fordert M2E eine Lizenz einzurichten. Dort gibt man die geforderten Angaben ein und bestätigt.

2) Amazon als Verkaufskanal aktivieren und konfigurieren

Amazon als Verkaufskanal aktivieren:

Am Einfachsten geht es, die Einstellungen wie unten im Bild zu übernehmen. Das wichtigste ist, Amazon als Default-Chanel zu wählen. Es öffnet sich ein Configuration-Wizard nach der Bestätigung. Dann startet die M2E Konfiguration.

Konfiguration von M2E :

Im Marketplace-Setup werden die Länder gewählt in denen die Produkte verkauft werden sollen. Über das Drücken auf weiter erscheint ein Ladebalken und ein weiterer Block, der zum Account-Setup führt.

3) Verbinden des M2E mit dem Amazon-Account

Im Reiter „Allgemeines“ und wählen man eine Bezeichnung für das Konto. Unter dem Punkt „Access Details“ wählen man den Marktplatz aus und drücken dann auf Zugangsdaten abfragen. Es öffnet sich, in einem neuen Fenster die Eingabemaske der Amaton-Seller-Central. Dort melden man sich mit den Zugangsdaten des Amazon-Accounts an.

Im darauf folgenden Fenster sollten alle nötigen Angeben schon vorausgefüllt sein. Man wählt die zweite Option und drückt weiter.

Im nächsten Fenster akzeptieren man die AGBs und kommt dann auf die Seite wo man die Verkäufer-ID und die Authorization-Token bekommt. Beides kopieren man und geht zurück zu den Settings im Magento-Backend. Unter dem Punkt Access-Details nun ID und Token eintragen. Man kann nun unter den übrigen Reitern weitere Einstellungen vornehmen. Dort kann zum Beispiel der Umgang mit Listings die Außerhalb von M2E getätigt wurden bestimmen. Das sind spezifische Angaben die von Shop zu Shop unterschiedlich sein können. „Speichern und fortfahren“ drücken.

Es erscheint nach dem speichern im oberen Teil der Seite eine grüne Fläche mit der Information, dass der Amazon-Account erfolgreich mit M2E verbunden wurde.

Angebot/Listing erstellen für Amazon

Listings machen im Grunde zwei Dinge – sie legen zu einen fest welche Produkte auf Amazon geführt werden und welche Einstellungen beim Amazon vorgenommen werden soll. Dies geschieht mit Hilfe von Rahmenbedingungen/Policies, dazu weiter unten mehr. Produkte können händisch in ein Listing hinzugeführt werden oder automatisiert, sobald ein neues Produkt angelegt wird. Ein Listing ist eine Schablone mit der eine bestimmte Art/Kategorie von Produkt unter den immer selben Umständen in Amazon erscheint.

Vorgehen:

Man drückt im Magento-Backend auf den Reiter „Amazon“ und wählt den Punkt „Angebote“. Es erscheint eine neue Seite. Oben rechts auf „Angebot hinzufügen“ klicken. Dort kann man nun Settings für das Listing konfigurieren. Die Einstellungen hier sind wieder individuell und variieren, je nachdem wie der Produktupload bei Amazon gestaltet werden soll. Felder die ausgefüllt werden müssen sind mit einem roten Sternchen markiert. Wichtige Felder sind unter dem Punkt „Selling Settings“ bzw. „Verkaufseinstellung“. Die Rahmenbedingungen/Policie müssen hinzugefügt werden, wenn noch keine Vorhanden sind. Dies kann über Policies hinzfügen direkt erledigt werden.

Selling Format Policy:

Mengenangaben und Preise bestimmen für die Anzeige auf Amazon. Mehr dazu auf:

https://docs.m2epro.com/display/AmazonMagentoV6X/Selling+Format+Policy

Synchronization Policy:

Hier werden die Einstellungen für den automatischen Upload auf Amazon vorgenommen wenn ein neues Produkt anlegt wird. Dies funktioniert laut M2E aber noch nicht Reibungslos. Daher ist empfohlen weitestgehend die Default-Einstellungen beizubehalten und nur mit rotem Sternchen gekennzeichnete Felder auszufüllen. Mehr dazu auf:

https://docs.m2epro.com/display/AmazonMagentoV6X/Synchronization+Policy

Vorweg: EAN und ISBN sind internationale Identifikationsnummern, ASIN ist eine Amazon-Artikelnummer die Amazon aus der EAN/ISBN bildet.

Nun fährt man fort mit dem Punkt „Sucheinstellungen“. Im besten Fall wird EAN, ISBN oder ASIN angegeben. Diese haben eine eindeutige Produktzuweisung und existieren nicht nochmal für ein anderes Produkt. Mit der Hilfe dieser Nummern kann man sich, wenn das gleiche Produkt schon von einem anderen Seller auf Amazon gelistet ist, das händische heraussuchen dieser Produkte sparen. Es funktioniert automatisch. Andernfalls wird M2E später beim Produkt-Upload auf Amazon die Möglichkeit geben Produkte aus dem Amazon-Produkt-Pool zu wählen. Noch nicht bei Amazon gelistete Produkte müssen eine EAN oder GTIN haben oder man hat die Möglichkeit bei Amazon um Freistellung zu bitten.

Auch hier alles je nach Bedarf ausfüllen und dann wartet der „nächste Schritt“.

Als Nächstes kann man angeben wie die Auswahl der Produkte angeordnet sein soll. Als Liste ohne Gruppierung oder geordnet nach Kategorien. Im Anschluss wird die Liste der Produkte dargestellt. Dort wählt man die Produkte aus, um diese dem Listing hinzuzufügen.

So hat man das erste Listing erzeugt. Dieses findet man nun im Backend des Shops unter Amazon->Angebote/Listing.

Produkt-Upload auf Amazon

1) Produkt-Upload mit EAN, ISBN oder ASIN

Zunächst folgt der Upload wenn man unter „Sucheinstellungen“ eine EAN, ISBN oder ASIN angegeben hat. Wenn man nun auf das Listing klickt öffnet es sich mit allen Produkten dieses Listings. Auf Amazon erscheinen dann die spezifisch ausgewählten Produkte. Nach der Auswahl findet man in der Tabelle ein Drop-Down-Menu „Schritte“, dort den Punkt „Artikel einstellen“ und daneben den Button „Absenden“. Es erscheint im oberen Teil des Backends und in der Produkttabelle die Nachricht, dass der Upload-Prozess gestartet ist.

Dieser dauert einen Augenblick. Bei einem erfolgreichen Upload änder sich in der Status in der gleichnamigen Spalte des Listings von „nicht eingestellt“ auf „eingestellt“.

Nun sind erfolgreich Produkte aus dem Shop zu Amazon hinzugefügt. Dies kann man, um sicher zu gehen, im Amazon-Seller-Central nachprüfen.

2) Produkt-Upload ohne EAN, ISBN oder ASIN

 Wie schon erwähnt falls das Produkt noch nicht bei Amazon selbst gelistet ist, muss eine EAN angeben werden oder um Freistellung gebeten werden. Dies gilt ausschließlich für den Upload bei Amazon. Für Ebay wird die Notwendigkeit der EAN etwas freier gehalten.

Im Listing sucht man sich das gewünschte Produkt und drückt nun auf das Kleine grüne Kreuz in der Spalte „ASIN/ISBN“.

Es öffnet sich ein Fenster mit drei Optionen. Zu wählen  ist „ASIN/ISBN manuell zuweisen“

Man kann nun in das Suchfeld oben im Fenster den Namen des Produktes eingeben. Wichtig ist, dass 100 % identische Produkte zu wählen. Hier muss man zusätzlich darauf achten, dass bei Kleidung auch die Farbe und Größe eine Rolle spielt. Diese haben jeweils andere EANs. Nachdem man sein Produkt unter den Vorschlägen gefunden hat, kann man diese „zuordnen“.

Nun sthet in der Spalte „ASIN/ISBN“ die Artikelnummer von dem ausgesuchten Produkt. Zum Nachkorrigieren  drückt man auf das kleine rote Minus neben der Lupe. Das Produkt wird von der ASIN entkoppelt. Wenn die Auswahl stimmt kann nun mit dem Produkt-Uploads fortgefahren werden.

Noch nicht alle Fragen beantwortet: das Lesen der M2E Dokumentation hilft in jedem Fall oder auch die webvisum GmbH aus Köln kann hier weiterhelfen.

Quelle Beitragsbild: commons.wikimedia.org/wiki/ File:Amazon_Espa%C3%B1a_por_dentro_(18).jpg

Der Beitrag M2E Pro in Magento 1 für Amazon – Konfiguration erschien zuerst auf Entwicklungshilfe NRW.

Was kann M2E Pro – eine kurze Einführung

Dies ist eine kurze Einführung in das M2E Pro Modul für Magento-Shops. Es bietet die Möglichkeit Produkte mit nur  direkt über den Magento Webshop auf Amazon, eBay und Rakuten anzubieten. Das spart Zeit, da nicht mehr verschiedene Systeme gepflegt werden müssen. Im Vorhinein können Einstellungen vorgenommen werden unter welchen Bedingungen das Produkt auf der jeweiligen Plattform erscheinen soll, zum Beispiel plattformabhängige Preise und Quantität. Diese Einführung beschäftigt sich nur mit der Plattform Amazon und soll helfen möglichst schnell die ersten Produkte zu platzieren.

M2E Pro lässt nahezu keine Option aus und ist sehr flexibel. Dem entsprechend greifen viele Abhängigkeiten ineinander. Vor allem die Rahmenbedingungen/Policies, unter denen Produkte hochgeladen werden, können sich im Weg stehen. Deswegen ist es wichtig zu wissen, dass eine gewisse Einarbeitungszeit benötigt wird, um M2E Pro intuitiv bedienen zu können. Vieles wird auch mit Hilfe dieser Dokumentation nicht direkt klar sein. Als weitere Hilfestellung auch noch andere Hilfe- und Informationskanäle zu Rate gezogen werden.

Einige Beispiele:

• Offizielle M2E Pro Dokumentation – Hier wird alles sehr ausführlich erklärt. Ausschließlich auf englisch: https://docs.m2epro.com/display/M2Ehome/Home
• Youtube – Dort gibt es viele Schritt-für-Schritt-Anleitungen. Hier ein gutes Video zur Konfiguration von M2E: https://www.youtube.com/watch?v=6jEgMhGLDKA
• Webvisum GmbH aus Köln, 0221 677834832 – wir haben schon für viele Kunden M2E Pro konfiguriert

Installation von M2E Pro bei Magento 1

Man hat zwei Möglichkeiten M2E Pro zu installieren, einmal über den Magento Connect Manager und einmal manuell in dem das Modulverzeichnis in das Magentoprojekt verschoben wird. Von der Installation über den Magento Connect Manager rate ich ab. Das gilt auch für Updates dieses Moduls. Die Installation selber sollte von einem Magento-Developer vorgenommen werden da es zu Problemen kommen kann, die den Shop still legen.

1) Magento-Extension-Key

Als Erstes benötigt wird der Magento-Extension-Key:

https://www.magentocommerce.com/magento-connect/ebay-amazon-rakuten-magento-integration-order-import-and-stock-level-synchronization.html

Dort etwas weiter nach unten scrollen, Reiter „M1 Extension Versions“.

Button „Install now“ drücken und einloggen, falls dies noch nicht geschehen ist. Jetzt einen weiteren Button „Get Extension-Key“ klicken, nachdem das darunterliegende Extension-License-Agreement akzeptiert wurde. Es erscheint ein Link zum Kopieren.

Dann folgenden Link klicken:

http://freegento.com/ddl-magento-extension.php

In das Eingabefeld den kopierten Link einfügen und auf „Senden“ drücken. Es erscheint ein Download-Link. Der Download des Archivs startet..

2) Einbinden des M2E Pro Moduls in den eigenen Magento 1 Shop

Für User mit einem UnixBetriebssystem(Linux, Mac OSX):

Das heruntergeladene Archiv entpacken und in das Magento-Verzeichnis verschieben. Die Installation von M2E Pro erfolgt entweder ganz einfach mit der Maus per Drag-and-Drop oder über die Konsole.

Per Drag-and-Drop:

Entpackt wird das M2E Pro Modul mit einem Doppelklick (bei Linux mit Rechtsklick und auswählen der „extract-here“-Option). Nun öffnet man sich am Besten den Projektordner der Magentoinstallation direkt daneben.  Nun den entpackten Inhalt markieren und mit gehaltener Alt-Taste (bei Linux die Ctrl-Taste) in die freie Fläche des Magentoverzeichnises ziehen. Ein kleines Plus steht neben der Maus. Unter Umständen sind danach die Ordner zusammen zu führen.

Per Konsole:

Die Konsole öffnen und in das Verzeichnis in dem das Archiv heruntergeladen wurde wechseln mit dem CD-Befehl(change directory). bsp „CD /Pfad/zu/meinen/Downloads“. Eingabetaste bestätigen.

Über die Eingabe von „ls -la“ in die Console erscheint eine Tabelle in der auch das M2E Pro Archiv sehen sollte.

Nun einen neuen Ordner erstellen, das M2E Pro Archiv in diesen Ordner verschieben und dort entpacken. Wir nennen unseren neuen Ordner „m2e_modul“. Hierzu sind folgenden Befehlen in der Console nötig:

mkdir m2e_modul

mv heruntergeladenesArchiv.tar m2e_modul

Jetzt in den neuen Ordner m2e_modul wechseln und das heruntergeladene Archiv entpacken über:

cd m2e_modul

tar -xvf heruntergeladenesArchiv.tar

rm -rf  heruntergeladenesArchiv.tar

Jetzt wird das entpackte Archiv in den Magentoordner verschoben:

cp -R * Pfad/zu/meinem/Magento

Nun ist das M2E Pro Modul installiert. Im Magento-Backend sind nun zwei weitere Reiter. „Bei eBay verkaufen“ und „Amazon“ verfügbar.

Davon ausgehend, dass zunächst lokal gearbeitet wurde, müssen die Änderungen natürlich noch auf den Live-Server bzw. Preview Server geschoben werden. Dazu kann man entweder ein FTP-Programm nutzen oder via Versionsverwaltung arbeiten.

Problembehandlung bei M2E Pro

1) WIe geht man generell mit Error Meldungen in M2E um

Im Allgemeinen wirft M2E Pro immer eine Fehlernachricht sobald etwas schiefgelaufen ist. Dort seht auch meistens was zu tun ist oder wo nachzuschauen ist. Wenn Sie in Ihrem Backend-Menu den Punkt „Amazon → Protokolle“ wählen, kommen Sie auf eine Seite auf der Sie unter dem Reiter „Angebote“ einen Log finden. Dieser Log speichert alle Ihre Aktivitäten die Sie ausgeführt haben. In der Spalte „Beschreibung“ sollten Sie im Falle eines Errors immer zuerst nachschauen, denn auch da stehen brauchbare Tipps.

Ansonsten können Sie natürlich auch auf die oben in der Einleitung beschriebenen Hilfsmittel zurückgreifen.

2) Mögliche Issues und Tipps für M2E Pro:

Errors noch der Konfiguration:

Sollten Sie M2E-Version 6.4.7. installiert haben und es erscheinen noch vor der Konfiguration Php-Erros o.Ä. dann sollten Sie auf 6.4.8 oder höher Updaten. Dazu sollte man nicht den Magento Connect Manager nutzen. Sollten Sie noch nie mit M2E Pro gearbeitet haben und haben dem entsprechen auch keine Policies angelegt können Sie um sicher zu gehen einfach alle M2E-Dateien und Verzeichnisse löschen. Dazu nutzen Sie am besten den Konsolenbefehl:

cd Pfad/zu/meinem/Magentoprojekt

find . -name ‚*M2e*‘ -exec rm -rf {} \

Der Beitrag M2E Pro – Installation & Einführung Magento 1 erschien zuerst auf Entwicklungshilfe NRW.

Paul Boisvert startet die Meet Magento mit der Keynote über Magento 2

Nach einem leckeren, jedoch kurzen Frühstück begann der erste Tag der Meet Magento mit einer Keynote von Paul Boisvert, dem Head of Product Management bei Magento. Es stellte die Roadmap für Magento2 vor mit einigen interessanten neuen Features sowie der Advanced-CMS-Integration für die Magento Enterprise Edition und dem wichtigen Hinweis, dass jeglicher Support und dementsprechend auch Sicherheitspatches für Magento 1 ab November 2018 eingestellt wird [Das wurde mittlerweile zurückgeszogen, es soll ein verlängertes EOL für Magento 1 geben]. Seiner Meinung – und der Stimme ich voll zu – sollten Shop-Betreiber langsam Magento 2 in Angriff nehmen und sich so für die Zukunft mit einer langfristig unterstützen Version von Magento sicher aufstellen. Deshalb sehe er den Fokus der diesjährigen Meet Magento klar auf Magento 2.

Gute Desktop Version eines Shops besser als schlechter mobile first Ansatz

Danach ging es für mich nach kurzem Talk mit alten Bekannten auf der Meet Magento in einen weiteren Vortrag von Jan Sperlich, der mir hochgelobt angekündigt wurde. Und ich muss sagen, ich wurde nicht enttäuscht. Die Kernaussage seiner Präsentation war: eine guter Desktop-Shop ist besser als eine schlechte mobile Website. Er präsentierte in einem Praxisbeispiel seines Unternehmens. Durch gezielte Optimierung der Onlinepräsenz (Desktop Website) und auch Optimierung der Darstellung auf mobilen Endgeräten (ohne dedizierte App) war es möglich, die Conversion Rate des besagten Shops signifikant zu erhöhen. Und zwar anders als mit einer separaten mobilen App. Das ließ den gesamten Saal feststellen, dass Responsive-Design anscheinend immer noch weit vor der Useability oder zumindest der Beliebtheit einer mobilen App liegen.

Suche das wichtigste Feature in einem Shop

Eher kurz fassen werde ich mich zu dem Talk von Dr. David Urbansky. Nach einer ausgiebigen Mittagspause mit lauter gesundem Zeugs und leckeren Wraps erzählte uns Dr. David Urbansky etwas über seine Theorie des wichtigsten Online-Shop Features überhaupt – der Suche.
Seine Kernaussage war, dass die Suche mittlerweile das mit Abstand wichtigste Feature einer Website ist. Er präsentierte eine ca 15 Punkte-Liste welche simple und auch komplexe Funktionen einer Suche enthielt und auf den Prüfstand stellte (Synonymsuche, Fön/Haartrockner, etc.). Ein insgesamt eher komplexer Vortrag mit jedoch auch sehr verständlichen Argumenten und Tipps für die Integration einer guten Suchen in Magento 2. Die Umsetzung ist jedoch seiner Meinung nach (auch durch die Magento Suchimplementierung) verbesserungswürdig. Dem Stimme ich und nicht wenige Leute aus dem Saal zu.

Nutzerfreundlichkeit für Suchmaschinenfreundlichkeit

Der letzte Vortrag für mich an diesem Tag war ein meiner Meinung nach sehr interessanter Vortrag von Mario Jung mit der Kernaussage: Baue die Website für den User und nicht für Google/Bing/Yahoo.
Er stellte eine Liste vor mit seinen 10 Tipps, wie man die Nutzerfreundlichkeit im Shop verbessert. Einige dieser Punkte sind sinnvoll und auch SEO-technisch relevant. Ein Vorschlag von Herr Jung, wie die Implementierung eines Chatbots zur Beantwortung von Kundenfragen halte ich jedoch für etwas gewagt. Den Rest seines Vortrags kann ich nur wärmstens empfehlen, denn er empfiehlt auch Testing, Strukturierung und andere sinnvolle Sachen die PHP/Javascript Programmierer gerne mal vergessen. Alles in allem stimmt seine 10 Punkte Liste und sollte bestimmt einigen Entwicklern helfen. Die Liste möchte ich euch nicht vorenthalten:

1. Biete dem Kunden gewohnte Sachen. (Logo links oben, Cart rechts oben, etc)
2. Produktfilter und erweiterte Suche anbieten
3. Chatbot (Automatisiert oder mit Person dahinter)
4. Ladezeit so gering wie möglich halten
5. Nicht an aussagekräftigen und individuellen Bildern sparen
6. Professionelle Produktvideos stellen einen zukünftigen Trend dar
7. Linkbuilding bringt einen erhöhten Traffic
8. Arbeite mit Screaming-Tools
9. Nie aufhören zu testen! (A/B-Tests, Unit, whatever)
10. Frage andere (Kritik annehmen, eventuell sogar ein feature für Kritikannahme bauen)

Nach einem bisschen Small Talk mit anderen Magento Entwicklern, sowie viel Kaffee und einem weiteren kleinen Vortrag ging es dann gegen 19 Uhr zur Aftershowparty. Wie jedes Jahr wurde auch diese Aftershowparty in der Moritzbastei abgehalten und bestach durch eine super Atmosphäre. Gesponsert von maxcluster gab es für alle reichlich zu Essen und zu Trinken so viel das Herz begehrte.

Testautomatisierung und Sicherheit

Der zweite Tag der Meet Magento begann für mich verspätet. Durch gefühlt 300 Talks mit Entwicklern, Agentur-Chefs und Organizern der Meet Magento wurde am Tag der Aftershowparty bis spät in die Nacht „genetzwerkt“. Nach dem die Verleihung des Meet Magento Awards bereits vorbei war, ging es für mich direkt weiter in einen Vortrag von Fabian Schmengler über Test Automation in Magento. Er erläuterte verschiedene Methoden um seine Magento Extensions mit verschiedenen Tests zu prüfen. [Ich habe hier mal über Codeception als Frontend Testframework gebloggt.] [Gratulation an dieser Stelle noch mal an Rico Neitzel für den Meet Magento People Award]
Nach einer Mittagspause und reichlich Kaffee zur Beseitigung der Folgen des Vorabends ging es in einen Vortrag von Anna Völkl. Ihr Talk war zum Thema Sicherheit in Online-Shops bzw. die Verbesserung dieser. Sie zeigte einige jüngere Beispiele auf in denen bei großen Online-Shops kritische Sicherheitslücken gefunden wurden. Zudem erklärte sie Methoden und Maßnahmen zur Verbesserung der Security in Magento Shops und deren Extensions. Trotz softwaretechnischer Fokussierung waren auch Monitoring und Konfiguration des Servers Teil Ihres Talks.

Der letzte Vortrag dieses Tages für mich war von Nils Kattau und handelte von der Optimierung der Sales bzw. der Conversion in Online-Shops. Ein sehr interessanter Vortrag mit einigen Praxisbeispielen der jedoch den Rahmen dieses Posts bei weitem sprengen würde.

Vorher leider den Hackathon verpasst

Damit war die Meet Magento für mich auch für dieses Jahr schon vorbei. Schlimm genug dass ich es dieses Jahr wieder nicht auf den Magento Hackathon geschafft habe. Dieser findet jedes 2-3 Tage vor der Meet Magento statt und sticht mit Community-Coding, viel Club-Mate und noch mehr „Netzwerken“ heraus.

Der Beitrag Recap Meet Magento 2017 – Leipzig erschien zuerst auf Entwicklungshilfe NRW.

Gerade im Webdevelopment erfordern die immer dynamischeren Marktentwicklungen und entsprechend hohen User-Erwartungen ein breites Weiterbildungsangebot für Webentwickler. In Metropolen wie Berlin, München und Köln oder Ballungsräumen wie dem Ruhrgebiet gibt es hierzu zahlreiche Möglichkeiten. Etwas anders sieht es hingegen in strukturschwachen Regionen bzw. abseits der großen Wirtschaftszentren aus. Selbst User Groups sind hier eher rar gesät.

„Wir sind hier in Großwallstadt schon etwas weit vom Schuss, wenn es um inhaltlich aktuelle Weiterbildungsmöglichkeiten für Webdeveloper geht“, sagt Philipp Packheiser, Geschäftsführer des Online-Marktplatzes für Kfz-Ersatzteile TEILeHABER. „Unsere Mitarbeiter müssten daher schon ins 50 Kilometer entfernte Frankfurt am Main fahren, um sich auf den neuesten Stand bringen zu lassen.“ Ein Problem, dass sich in ähnlicher Weise auch den Auszubildenden des unterfränkischen Ausbildungsbetriebs stellt, da der Lehrplan der örtlichen Berufsschule aufgrund der eingangs umrissenen Situation naturgemäß immer ein wenig der Zeit hinterherhinkt. „So betrachtet kommt uns das Vor-Ort-Schulungsangebot von Entwicklungshilfe NRW da sehr entgegen“, so Packheiser weiter. „Denn wir halten es für absolut unabdingbar, dass sich unsere Entwickler regelmäßig mit modernen Technologien auseinandersetzen.“

Einführung automatisierter Frontend-Tests

Gesucht hatte das 2007 gegründete Unternehmen unter anderem nach Schulungen zu automatisierten Testings und war über einen Fachbeitrag von Roland Golla im PHP Magazin auf Entwicklungshilfe NRW aufmerksam geworden. Die Wahl fiel auf die PHP-Schulung Code Rocker, die eine Art Best-of aus dem gesamten Schulungsangebot ist und einen schnellen Einstieg ins Thema ermöglicht. Mit dem 22. September 2016 wurde dann ein Schulungstermin für zwei Fachinformatiker Anwendungsentwicklung, drei Azubis Anwendungsentwicklung und den Scrum Master von TEILeHABER vereinbart.

„Wenn man eine Plattform betreibt, auf der zig Millionen einzelne Artikel angeboten werden, dann kommt man mit manuellem Frontend-Testing natürlich nicht allzu weit“, sagt Golla, der als Dozent vor Ort beim Kunden war. „Beziehungsweise bindet man dadurch jede Menge Kapazitäten, die man besser woanders einsetzen kann.“ Daher bestand das Ziel der ganztägigen, sehr individuell gehaltenen Schulung zum einen darin, einige wichtige neue Technologien und Tools vorzustellen sowie einen ersten automatisierten Test für den Shop umzusetzen, und zum anderen sollte der Workflow des jungen Teams optimiert werden, um damit die Weichen für Continuous Integration zu stellen.

Tooling und Set-up signifikant verbessert

Die Schwerpunkte lagen damit auf den Themen Codeception Frontend Testing und PhpStorm Best Practice. Zudem wurde der PHP Mess Detector vorgestellt und eingesetzt. Mit diesem lassen sich Probleme im bestehenden Code aufspüren, darunter etwa Flüchtigkeitsfehler. Alles sehr praxisnah und ganz am aktuellen Bedarf des Kunden orientiert. Die größtmögliche Praxisnähe ist ja seit jeher der Kerngedanke von Entwicklungshilfe NRW: Somit sollen die geschulten Teams in die Lage versetzt werden, das neue Wissen sofort praktisch ein- und umsetzen zu können.

„Der Tag ist echt super gelaufen“, befindet Golla. „Die Jungs haben sehr gut mitgemacht und das neue Wissen nur so aufgesaugt. Ich denke, dass ich dem Entwickler-Team von TEILeHABER schon mit diesem ersten Schritt entscheidend weiterhelfen konnte.“ Seiner Einschätzung nach wurde das Tooling und Set-up des Teams dadurch signifikant verbessert. Eine Einschätzung, die Packheiser rundum teilt: „Wir sind mehr als zufrieden mit dem Ergebnis und können uns gut vorstellen, auch in Zukunft das Weiterbildungsangebot von Entwicklungshilfe NRW zu nutzen.“

Hier erfahrt ihr mehr über das PHP-Schulungsangebot von Entwicklungshilfe NRW.

Der Beitrag Entwicklungshilfe NRW schult Team von Online-Marktplatz erschien zuerst auf Entwicklungshilfe NRW.

In diesem Artikel befassen wir uns mit den mit der Ladezeit-Optimierung von Magento Shopsystemen. Magento ist ein umfangreiches Shopsystem und ist in bestimmten Konfigurationen anfällig für Performance-Probleme. Die fünf größten Fehler mit teils massiven Auswirkungen auf die Magento-Performance haben wir hier für euch aufgelistet und erklären mögliche Lösungen.

Die 5 häufigsten Fehler bei der Ladezeit-Optimierung

1) Ladezeit-Optimierung durch Verwendung der richtigen Festplatte

Magento ist wie schon erwähnt ein umfangreiches System welches in der Ausführung „Community Edition“ mehr als 15.000 Dateien beinhaltet. Das auf PHP basierende Shopsystem arbeitet mit zahlreichen Funktionen, welche die Festplatte massiv beanspruchen. Dazu gehören das Schreiben in Logfiles (access, system, exception log), das Anfordern von Files (require, file_get_contents) und das Laden von Daten aus der Datenbank. Der Einsatz einer SSD anstelle einer HDD lohnt sich beim professionellen Einsatz von Magento umso mehr, da die Magento-Performance drastisch verbessert wird.

Bildquelle: https://blog.amasty.com

2) Ladezeit-Optimierung durch Verwendung eines Caches

Magento benutzt wie die meisten großen System ein internes System zum Cachen von Daten, um die Ladezeit zu verkürzen. Es können verschiede Cache-Arten verwendet werden, welche nachfolgende Vorteile und Nachteile mit sich bringen. Wir werden dies anhand von 3 Beispielen kurz erläutern.

2.1) APC / Memcached

Diese beiden Cache-Arten benutzen den internen Speicher (RAM) des Servers zum Cachen der Daten von Magento. Der Nachteil dieser beiden Cache-Varianten ist, dass RAM zum Beispiel auf einem Shared Server nur in Maßen zur Verfügung steht und sparsam damit umgegangen werden muss. Der Vorteil ist dass diese Cache-Arten relativ schnell sind, da sie kleine Datenmengen aus dem RAM schnell ausliefern können.

2.2) Der Datenbankcache

Der Datenbankcache ist eine separate Cache-Art und kann unabhängig von den beiden anderen Cache-Arten benutzt werden. Dieser Cache ist zuständig für das Zwischenspeichern von öfter ausgeführten Queries die sich ansonsten mit minimalen Änderungen wiederholen würden. Magento speichert diese Art von Anfrage im RAM zwischen und führt diese dann aus ohne jedes mal erneut mehrere Datenbankabfragen an den Server zu stellen. Der Datenbankcache kann bei genügend vorhandenem RAM oder schnellem Festplattenspeicher zu einer signifikanten Optimierung der Ladezeit führen, da Magento mehrere Queries pro Seitenaufruf benötigt und diese eingespart werden können.

2.3) Der Filecache

Dieser Cache benutzt das interne Dateisystem zum Vorhalten der Daten. Die Vorzüge dieser Cache-Art ist, dass er in Kombination mit einer SSD sehr schnell ist und die üblichen RAM limits von APC / Memcache getrost ignorieren kann, da er lediglich ein wenig Festplattenkapazität voraussetzt. Der Nachteil jedoch ist, dass diese Art von Cache ohne eine SSD extrem langsam ist. Wie beim Datenbankcache wird der Filecache das gesamte System ohne eine SSD mehr ausbremsen als beschleunigen.

Seit der Version 5.5 von PHP wird Zends sogenannter OpCache (Opcode-Cache) mitgeliefert und standardmäßig installiert. Dieser Opcode-Cache ist schnell und kostengünstig in der RAM-Benutzung. Sollte PHP 5.5 oder höher auf dem Magento System installiert sein, empfiehlt es sich den von PHP mitgelieferten OpCache in Kombination mit dem Filecache zu benutzen, sofern eine SSD vorhanden ist.

3) SQL Statements

Ein nicht zu verachtender weiterer Punkt in der Liste der Performance-Flaschenhälse sind SQL Statements. Dabei geht es hier nicht um eine bestimmte Art von SQL Statements, sondern um deren Verwendung. Das folgende Beispiel ist ein Auszug aus einem Magento Modul welches 9 Produkte einer Kategorie per AJAX nachlädt und im späteren Verlauf verarbeitet und ausgibt.

foreach ($this->getProductIds() as $productId){
    $product = Mage::getModel('catalog/product')->load($productId);
    $this->processProduct($product);
}

Wie im Code zu sehen ist, werden bei jedem Aufruf des PHP-Skripts die Produkt-IDs geladen und dann in einer foreach Schleife das jeweilige Produktmodel geladen. Das Problem dabei ist, dass jedes Produktmodel einzeln geladen wird und für jedes dieser Produkte mehrere Queries verwendet werden. Bei einer Anzahl von 500 Produkten sind wir somit bei sage und schreibe ca 2500-5000 SQL-Queries, je nachdem wie viele Attribute die besagten Produkte besitzen. Der richtige Weg unter Berücksichtigung der Magento-Performance und Logik sieht wie folgt aus:

$collection = Mage:getResourceModel('catalog/product_collection')
    ->addFieldsToFilter('entity_id', array($this->getProductIds()))
    ->addAttributeToSelect(array('name'));

foreach ($collection as $product){
    $this->processProduct($product);
}

Hier wird die ganze Produktkollektion nur ein mal geladen. Nachdem die Filter hinzugefügt wurden, werden die Produkte dann mit einer Schleife über die $collection variable verarbeitet. In diesem Code werden maximal ein bis zwei Dutzend SQL queries verwendet, was sich spürbar auf die gesamte Ladezeit der Seite auswirkt.

Quelle Beispiel: http://labs.octivi.com/ (Bad SQL Queries)

4) Ladezeit-Optimierung durch Verwendung vorgerenderter Bilder

Magento wird in seiner Standard-Konfiguration mit zahlreichen Bilder ausgeliefert. Sobald ein Shopbetreiber seine Produkte und dazugehörige Bilder anlegt, ist man schnell bei ~20-30 Bildern pro Kategorieseite und noch mehr Bildern auf der Produktdetailseite angelangt. Je nach Berücksichtigung der durchschnittlichen Bildgröße, so um die ~0.5-2 Megabyte an Daten betragen dürfte. Auch Bilder welche in ihrer Dimension zu groß sind, sollten vor dem Verwenden verkleinert werden, um so wertvolle Bandbreite zu sparen und mobile Shopbesucher nicht mit größeren Datenvolumen zu belasten. Die richtige Größe der Bilder sowie deren Optimierung durch ein externes Werkzeug wie optipng bewirken eine schnellere Ladezeit der Seite durch weniger Datenvolumen und macht sich schnell auch im praktischen Testen bemerkbar.

5) Steigerung der Magento-Performance durch Verwendung der neuesten PHP Version.

PHP hat seit Version 5.5 einen enormen Geschwindigkeitszuwachs erhalten. Jetzt, mit Version 7.0, ist die Sprache auf der Magento sein Grundgerüst aufbaut sogar doppelt so schnell wie sein Vorgänger PHP 5.5 bzw 5.6 und somit um ein Vielfaches schneller als das immer noch weit verbreitete PHP 5.4. Deshalb ist es empfehlenswert bei einer Magento-Installation, mindestens PHP in der Version 5.5 bzw 5.6 auf dem Server installiert zu haben. Der eingebaute Zend OpCache ab Version 5.5 beschleunigt einen frisch installierten Magento Shop um bis zu ~40% ohne jegliche Änderungen an der Konfiguration oder der Hardware. PHP Version 7.0 steigert diesen Geschwindigkeitszuwachs noch einmal um satte 100% durch die effektivere Handhabung von Arrays und großen Objekten, von welchen Magento durchweg exzessiven Gebrauch macht. Eine Magento-Installation mit PHP 7.0 lädt im Vergleich zu einer Magento installation mit PHP 5.4 um bis zu 1.6 Sekunden schneller.

Bildquelle: https://www.mgt-commerce.com/blog/

Fazit

Durch Befolgen der genannten 5 Aspekte kann man ohne viel Aufwand bereits eine spürbare Steigerung der Magento-Performance erreichen. Natürlich gibt es weitere Punkte, welche die Geschwindigkeit einer Magento-Installation beschleunigen können. Wir haben uns hier jedoch auf die Punkte mit den prozentual größten Geschwindigkeitseinbußen bei Missachtung konzentriert.

Der Beitrag Magento-Performance: Flaschenhälse erschien zuerst auf Entwicklungshilfe NRW.

Eine Standard Magento Konfiguration wird bereits mit über 20 JavaScript-Dateien ausgeliefert. Somit ist für die meisten Entwickler schnell klar, dass die Reduzierung des JavaScripts oder dessen Zusammenführung in einer Datei anstatt 20 einen Geschwindigkeitsvorteil und eine bessere Performance bringen wird. Verbunden ist dies mit vergleichsweise wenig Aufwand im Gegenteil zu anderen Optimierungsmaßnahmen. Für solche Fälle bietet Magento standardmäßig die Funktion „JavaScript-Dateien kombinieren“, welche jedoch mehr Nachteile als Vorteile mit sich bringt. Die Nachteile werden wir in diesem Blogpost anhand von drei Beispielen detailliert erläutern.

Die Ausgangssituation:

Bei der Verwendung des von Magento bereitgestellten Features werden alle JavaScript-Dateien in einer Datei kombiniert, aus der Größe des Contents einen Hash generiert und als Datei abgespeichert. In unseren weiteren Beispielen benutzen wir anstatt der Hashes einfache Namen wie zum Beispiel „abc.js“ und „xyz.js“. Die Magento-Entwickler haben bei der Implementierung ihres Features jedoch einige zum Teil gravierende Fehler nicht berücksichtigt.

Fehler 1: Minimierte oder kombinierte JavaScript-Dateien können den ganzen Shop unbenutzbar machen!

Sobald 2-3 minimierte JavaScript-Dateien in das bestehende Shopsystem integriert werden, treten bereits die ersten Probleme auf.
Auch wenn der Entwickler auf die Idee kommen sollte Magentos JavaScript-Dateien zu komprimieren, wird es unter Umständen zu Fehlern kommen.
Das Problem an der Sache ist der Coding-Style der Magento Entwickler. JavaScript ermöglicht es beendete Funktionen ohne Semikolon abzuschließen, wovon die Magento Entwickler sehr oft Gebrauch machen. Sollte nun ein Entwickler die Magento JavaScript-Dateien zur Performance- und/oder Ladezeitoptimierung komprimieren und die Kombinierfunktion einschalten, entstehen dadurch kritische Fehler.

Durch das Komprimieren der Dateien schrumpft der Dateiinhalt auf exakt eine Zeile. Sobald beispielsweise eine „var“ Deklaration am Anfang der zweiten Datei steht und in der ersten Datei eine Funktion ohne abschließendes Semikolon beendet wurde (was in 95% der Fälle zutrifft), wird der Code fehlerhaft geparsed und beide Dateien verlieren Ihre eigentliche Funktionalität.

Fehler 2: Kombinieren der JavaScript-Dateien birgt das Risiko, die Ladezeit der Seite zu erhöhen!

Jetzt fragen sich sicherlich einige, wie dass denn überhaupt möglich ist wenn man doch anstatt 20 Dateien nur noch eine lädt und somit die HTTP-Requests in Folge der JavaScript-Optimierung massiv gesunken sind. Die Frage lässt sich durch ein einfaches Beispiel illustrieren. Nehmen wir an, auf der Startseite des Shops werden die JavaScript-Dateien „abc.js“ und „xyz.js“ geladen. Diese Dateien werden überall geladen. Nach dem Aktivieren der Kombination werden diese zu (Beispiel) „abcdef.js“ kombiniert. Wenn der Nutzer die Startseite besucht wird die Datei einmal ausgeliefert und danach gecached. So weit, so gut. Sollte der Nutzer jedoch eine Produktseite besuchen, welche außer „abc.js“ und „xyz.js“ auch noch „foo.js“ und „bar.js“ benötigt, wird nochmals eine kombinierte Datei erstellt (Beispiel) – „ghijkl.js“. Da der Nutzer bereits die beiden ersten Dateien im Cache hat, muss der Browser jetzt unnötiger Weise trotzdem beide Dateien in Form von ghijkl.js ausliefern, welche auch „foo.js“ und „bar.js“ enthält.

Fehler 3: Massiver Overhead ohne jeglichen Nutzen bei Verwendung von Protokollen wie SPDY oder HTTP/2

Falls der Shopbetreiber bzw. dessen Entwickler einen Server betreiben, welcher die Protokolle SPDY oder dessen standardisierten Nachfolger HTTP/2 benutzt, ist die ganze Kombination von JavaScript-Dateien als JavaScript-Optimierung mehr Nachteil als Vorteil. Die HTTP/2 Spezifikation erlaubt es, parallel in nur einer einzigen HTTP-Request JavaScript-Dateien auszuliefern. Je nach Größe und Masse der einzubindenden JavaScript-Dateien kann dies beim Kombinieren zu erheblichen Leistungseinbußen führen. Angenommen ein großer Shop hat 40 JavaScript-Dateien, wobei einer dieser Dateien eine für JavaScript gigantische Größe von 700 Kilobytes hat. Diese Datei wird beim Kombinieren jedes mal gelesen und wieder in die kombinierte Datei geschrieben. Dieser Overhead ist bei der Verwendung von SPDY oder HTTP/2 unnötig und verursacht eine deutlich spür- und messbare Erhöhung der „Time To First Byte“, die Zeit die der Shop zum Senden des ersten Bytes an den User braucht.

Testszenarien und Auswertungen der JavaScript-Optimierung

Die hier gezeigten Ausschnitte des Testtools Webpagetest sollen lediglich der Illustration des Ladevorgangs dienen.
Die Zeiten der einzelnen Dateien sind hier nicht wirklich relevant, da wir kein wiederhol- und überprüfbares Testsetup aufgesetzt haben. Das soll in einem späteren Thread aber folgen.

Ladevorgang bei Verwendung von HTTP/1.1

Ladevorgang bei Verwendung von HTTP/1.1 mit Kombinierungstool

Ladevorgang bei Verwendung von HTTP/2

Ladevorgang bei Verwendung von HTTP/2 mit Kombinierungstool

Fazit

Trotz eines eingebauten JavaScript-Kombinierungstools ist es nicht ohne Weiteres möglich, Magentos eingebaute Performance Tools wie „JavaScript-Dateien kombinieren“ in einem produktivem Umfeld ohne ausgiebiges manuelles Testen zu benutzen. Es können schnell unverschuldet Fehler entstehen, welche die ganze Seite unbenutzbar machen. Des weiteren kann bei Benutzung von Magentos Funktion schnell eine Erhöhung der Seiten-Ladezeit anstatt der gewünschten Reduzierung eintreten.

Der Beitrag JavaScript-Optimierung in Magento erschien zuerst auf Entwicklungshilfe NRW.

In der Welt der Versionskontrollsysteme ist Git mit Abstand eines der effektivsten und einfachsten Tools die uns zur Verfügung stehen, um unseren Arbeitsalltag bzw. unseren Workflow zu optimieren. In diesem Artikel zeigen wir euch, wir ihr Git mit git-flow effektiver nutzt.

Git Branching

Wir gehen in unserem Beispiel davon aus, dass zwei neue Features für unser aktuelles Projekt geplant sind. Diese wollen wir, ohne uns als Entwickler gegenseitig auf die Füße zu treten, zeitgleich erledigen.

Dafür gibt es in Versionskontrollsysteme sogenannte Branches. Bei Git enthält jeder Branch eine eigene Kopie des jeweiligen Repositories zum Zeitpunkt der Erstellung des Branches. Den Verlauf einer Feature-Entwicklung im normalen Git-Workflow erklärt der nächste Absatz. Person A erstellt hier zum Beispiel eine Navigation speziell für Smartphones in unserem Projekt.

Einfacher Workflow ohne Branching-Modell:

Als erstes beziehen (clonen) wir das Git-Respository vom Server, um eine lokale Kopie des gesamten Projektes zu erhalten. In diesem wird nun auf dem Hauptbranch (Master) das Feature „Smartphone Navigation“ nach und nach programmiert. Die Schritte schliessen jeweils mit commit und anschliessendem push der Änderungen an das globale Repository ab. Die Webseite auf dem Produktions-Server wird anschliessend mit einem pull aktualisiert.

Das Problem an diesem Beispiel ist Folgendes:
Sobald eine weitere Person am selben Projekt arbeitet kann es zu Überschneidungen kommen. Angenommen Person A arbeitet an der Smartphone Navigation während Person B einen wichtigen Bugfix einspielt. Dadurch, dass Person B seinen Bugfix so schnell wie möglich auf der Live-Instanz des Projektes haben will, wird nach dem Hinzufügen des Bugfixes sofort der Master-Branch auf den neusten Stand gebracht. Das hat die Nebenwirkung zur Folge, dass auch Teile des Codes von Person A auf den Live-Server geladen werden und somit Probleme bzw. Fehler produzieren werden, da man nicht sicher sein kann, dass Person A seine Arbeit beendet hat. Und seien wir ehrlich – in Projekten mit mehr als einem Entwickler kommt es IMMER zu solchen Zuständen.

Lösungsansatz mit Git und einem einfachen Branching-Modell

Um solche Probleme zu umgehen hat man in Git die Möglichkeit einen oder mehrere Branches zu erstellen. Ein Branch ist eine Abzweigung der Codebasis zu einem bestimmten Punkt. Ab diesem Punkt kann man auf seinem Zweig (Branch) parallel zum Beispiel zum Hauptstrang in Ruhe entwicklen und erst das fertige Feature wieder zurück mergen.

Hier ein Beispiel:
Person A möchte eine Navigation für Smartphones erstellen ohne jemandem in die Quere zu kommen und geht jetzt wie folgt vor:
Git-Repository vom Server ziehen für eine lokale Kopie des gesamten Projektes. Neuen Branch erstellen mit dem Namen „develop“.
Auf diesem Branch kann jetzt unabhängig von anderen Branches weiter gearbeitet werden. Jegliche Änderung auf dem neu erstellten Branch wird zunächst keinerlei Auswirkung auf andere Branches haben. Sobald das neue Feature fertig ist, wird Person A seine Änderungen pushen und seine Änderungen in den Hauptbranch „mergen“ (zusammenführen).
Dieses Merging vom Branch „develop“ in den Hauptbranch des Projektes bewirkt, dass alle Änderungen im Smartphone Branch nun auch auf dem Hauptzweig des gesamten Projektes verfügbar sind.

Sollte während der Entwicklungszeit der Smartphone-Navigation Person B einen kritischen Bugfix in den Hauptbranch pushen, kann der Administrator ohne Einfluss der Codeänderungen für die Smartphone-Navigation den Hauptbranch updaten. Der Bugfix der auf dem Hauptbranch von Person B eingefügt wird, hat keinerlei Auswirkungen auf die Arbeit von Person A (Smartphone-Navigation Branch). Auch werden Codeänderungen von Person A keinen Einfluss auf die Arbeit von Person B haben, da beide verschiedene Branches verwenden.

Wenn dann jedoch nach der Fertigstellung der Smartphone-Navigation das gesamte Projekt diese neue Navigation erhalten soll, wird der Branch des neuen Features, in unserem Fall „develop“, einfach mit dem Hauptbranch zusammengeführt, woraufhin alle anderen Projektmitglieder die neuen Änderungen schließlich auch erhalten. Ausgenommen davon sind natürlich wieder die Projektmitglieder, die sich gerade auf einem anderen Branch befinden.

Lösungsansatz git-flow als Branching-Modell

„Git-flow“ ist ein Tool das den Workflow von Git erweitert und fest spezifiziert. Es kann per Kommandozeile oder per Tool bedient werden. So bieten zum Beispiel Sourcetree von Atlassian und PhpStorm Untersützung für git-flow. Die sehr feste Spezifizierung von git-flow hält den Workflows konstant und fördert den dezentralisierten Entwicklungsansatz. Zusätzlich zu den bekannten Hauptzweigen „master“ und „develop“ werden sogenannte Support-Branches erstellt, welche später für differenzierte Aufgaben verwendet werden. Diese werden auf verschiedene Art und Weise mit unseren Hauptzweigen „master“ und „develop“ zusammengeführt. Wir werden diese Support-Branches anhand von drei Beispielen kurz erklären.

Support-Branches bei git-flow

Derzeit haben wir in unserem Projekt zwei Zweige, „master“ und „develop“. „Master“ ist die aktuelle Live-Version des Projektes während „develop“ einen aktuellen Entwicklungsstand darstellt. „Git-flow“ fügt nun drei weitere Arten von Branches zu unserem Workflow: „release“, „feature“, und „hotfix“.

Hotfix-Branches

Der Hotfix-Branch wird von den beteiligten Entwicklern lediglich dazu benutzt Fehlerbehebungen des Live-Systems durchzuführen. Sobald ein Fehler behoben ist, wird der Hotfix-Branch geschlossen und mit „master“ und „develop“ zusammengeführt. Dieses führt auf der einen Seite zu einem sauber aktualisierten Live-System und auf der anderen Seite wird der Hotfix in die Entwicklungsschiene transferiert, da sämtliche anderen Branches vom „develop“ Branch abhängen.
Hotfix-Branch Workflow © nvie.com

Feature-Branches

Der Feature-Branch wird als Zweig zur Erstellung neuer Funktionen verwendet. Sobald eine neue Funktionalität abgeschlossen ist, wird der Feature-Branch auf mit dem Develop-Branch zusammengeführt und kann auf einer Testinstanz unabhängig von unserem Master branch getestet werden. Feature-Branches sollten in dieser Struktur lediglich lokal vorkommen.
Feature-Branch Workflow © nvie.com

Release-Branches

Der Release-Branch wird bei jedem neuen Release oder großen Codeänderung (Milestone) benutzt. Ein Release kann zum Beispiel eine Sammlung von verschiedenen Features sein, welche als Release-Branch gruppiert bzw. zusammengefasst werden, um gemeinsam deployed zu werden. Ein Release-Branch sollte immer mit „master“ als auch „develop“ zusammengeführt werden, wobei letzterer für die Qualitätssicherung inklusive Testing Vorrang hat.

Fazit

Das Arbeiten mit git-flow oder generell die korrekte Nutzung von Branching stellt eine qualitätssichernde sowie Workflow-optimierende Maßnahme da, die uns hilft sauber und getrennt voneinander unseren Aufgaben nach zu gehen, ohne die Arbeit des Anderen zu beeinträchtigen.

Der Beitrag git-flow – das Branching-Modell erschien zuerst auf Entwicklungshilfe NRW.

Die Installation

Codeception kann hier via Composer installiert werden. Jedoch wird davon in unserem Beispiel kein Gebrauch gemacht, da wir den sofortigen Einsatz von Codeception auf einer frischen VM realisieren, und somit keinen Composer installiert haben.

Mac/Linux:
Auf dem Mac bzw Linux und Unix derivaten kann Codeception auch per Command-line installiert werden.

wget http://codeception.com/codecept.phar && php codeception.phar bootstrap

mit diesem beidem Befehlen wird Codeception installiert und dessen Ordnerstruktur erstellt.

Windows:
Auf Windows muss das installationsarchiv hier manuell heruntergeladen werden von:

Nach der Installation auf Windows hat Codeception die benötigte Ordnerstruktur erstellt.

Sollte das Frontend-Testing mit Google Chrome, Firefox oder anderen Browsern durchgeführt werden, wird auch Selenium benötigt. Die Installation kann auf einem Mac/Linux per Kommandozeile mit folgenden Befehlen geschehen.

Mac:

brew install selenium-server

Linux:

apt-get install selenium-server

Auf Windows muss der Selenium Server von http://selenium.org heruntergeladen und installiert werden.

Nachdem Selenium und Codeception installiert sind, gestaltet sich der Rest der Konfiguration relativ einfach. Zunächst können im „_env“ Verzeichnis von Codeception sogenannte Testumgebungen angelegt werden, welche der Reihe nach von Codeception durchlaufen und abgearbeitet werden. Ein Beispiel für einen solche Datei sieht wie folgt aus.

In diesem .yml file wird festgelegt, dass der zu testende Browser Google Chrome sein wird.
Des Weiteren wird festgelegt, dass wir in der Auflösung 1920×1080 testen werden.
Die URL kann pro Testumgebung jeweils eine URL beinhalten, welche in unserem Testszenario momentan auf einen unserer Testserver zeigt.

Vorbereitungen für das Frontend-Testing

Nachdem wir unsere Umgebungsvariablen festgelegt haben, können wir uns der nächsten wichtigen Datei widmen. Die Datei __bootstrap.php aus dem Verzeichnis „acceptance“ wird vor jedem Test aufgerufen und erlaubt es, Variablen zu deklarieren die dann in den jeweiligen Testszenarien verwendet werden können. Diese Variablen bestehen den ganzen Test über und können von den verschiedenen Szenarien gemeinsam benutzt werden. Eine sinnvolle Verwendung dieser Datei wäre zum Beispiel eine Funktion zum erkennen des benutzten Browsers, um in den Tests darauf entsprechend reagieren zu können und die Tests für den jeweiligen Browser besser anzupassen.

Beispiel: Sollte die Funktion in __bootstrap.php ein mobiles Endgerät entdecken, kann der darauf folgende Test in seinem Testszenario darauf reagieren und zum Beispiel die mobile Navigation anstatt die normale Navigation Testen.

Hinweis: Bevor die Testszenarien durchlaufen werden können, muss Selenium entweder auf Windows mit einem Doppelklick, oder auf Mac bzw Linux/Unix derivaten mit dem Konsolenbefehl „selenium-server -p 4444“ gestartet werden.

Das Testszenario

Kommen wir nun zu den eigentlichen Tests. Jedes Testszenario das wir anlegen wollen, muss sich im „acceptance“ Verzeichnis befinden. Jede PHP datei außer __bootstrap.php wird dort für jede einzelne Testumgebung die wir im „_env“ Verzeichnis liegen haben durchlaufen. Haben wir zum Beispiel ein Testszenario wie „Navigation.php“ im „acceptance“ folder, wird dieses Szenario für chrome_1920x1080.yml aufgerufen.
Ein Beispiel eines solchen Tests sieht wie folgt aus.

amOnPage("/");
    $I->wantTo("test elements of the navigation (upper categories)");
    $I->click(".menu-button");
    $I->click("#nav-wide .level0.nav-1 a span");
    $I->moveMouseOver("#nav-wide .level0.nav-1 a span");
    $I->click(".level1.nav-1-1  a span");
?>

Der obrige test wurde mit dem Befehl „php codecept.phar run acceptance –env chrome_1920x1080“ aufgerufen. Für jede weitere Testumgebung die in die Testszenarien eingebunden werden soll, wird eine weitere –env Direktive benötigt.

Beispiel 2 Browser:

php codecept.phar run acceptance --env chrome_1920x1080 --env firefox_1920x1080

Hint: Während eines Tests der Funktionen wie $i->moveMouseOver() enthält darf die Maus nicht bewegt werden!

Je nach Generalisierung der Tests wie Beispielsweise oben beschrieben, lässt dich der Test für mehrere Anwendungszwecke verwenden. In unserem Fall ist der oben zu sehende Test für jegliches Login-Formular einer Magento-Shop Webseite einsetzbar.

Nachdem Codeception die Tests erfolgreich (oder auch nicht) beendet hat, wenden wir uns dem Verzeichnis „records“ zu. Im Verzeichnis „records“ befinden sich Screenshots von jedem einzelnen Schritt unserer Tests und dem Ergebnis. Es bleibt einem die Möglichkeit entweder die Datei „index.html“ zu öffnen und sich in einem minimalistisch gestalteten Web-interface durch die Ergebnisse zu klicken oder sich die einzelnen Fehlgeschlagenen Tests heraus zu suchen. Fehlgeschlagene Tests haben eine „.fail.“-Endung im Dateiname und sind direkt in „records“ Ordner zu finden.

Hint: Der Befehl $i->wait() veranlasst Codeception dazu, eine gewisse Zeit zu warten und einen neuen Screenshot zu erstellen.

Fazit:

Codeception ist ein effizient einsetzbares Tool mit noch kleinen Schönheitsfehlern, wie zum Beispiel das unnötige Erstellen eines Screenshots nach Verwendung des $i->wait() Befehls, die einen Entwickler jedoch keinesfalls am produktiven Einsatz des Frameworks hindern. Es stellt mit seiner einfachen Syntax und leichten Bedienbarkeit eine effektive Methode für das Frontend-Testing dar.

Der Beitrag Frontend-Testing mit Codeception erschien zuerst auf Entwicklungshilfe NRW.

Mein Plan als Magento-Entwickler für das Wochenende

Mein Plan war es eigentlich, für mein bestehendes Projekt und die darin schon gefundenen Stolpersteine Hilfe zu finden. Aus Entwickler-Sicht ist das Projekt relativ klein, da es sich lediglich um eine Migration von Magento 1.x auf 2.x ohne aktivierte Einkaufsmöglichkeit handelt. Damit entfällt die ganze Warenkorb/Checkout/AfterSales-Funktionalität. Auch E-Mail-Templates sind nicht großartig zu beachten. Das Projekt enthält jedoch ein komplettes Redesign. Damit kam es mir als Einstiegsprojekt für eine Migration sehr gelegen.

Die Stolpersteine, die sich so auftaten, während ich mich alleine mit den Dokus ans Projekt machte, tauchten an diesem Wochenende auch bei anderen auf – puuh, ich war also nicht alleine.

Da wäre zum Beispiel die einfache Aufgabe, Nummer 2 erstmal ans Laufen zu kriegen. Der Umstieg der anwesenden, durch die Bank erfahrenen alten Magento-Hasen auf das Neue-und-Alles-ist-besser-Magento gelang nicht ganz so flüssig, wie die Magento-Marketingler das gerne auf allen Kanälen hinausschreien. Beim ersten Anlegen des Projektes damals liefen bei mir die Installation und auch alles andere reibungslos. Beim Anlegen der neuen Installation für das Wochenende aber hatte ich dann Probleme damit und habe mir nebenbei mit einem Update von Version 2.0.0 auf 2.0.1 das oben beschriebene Projekt so zerschossen, dass nur noch ein Backup half.

Auch die ersten Schritte eines eigenen Templates mit der Frage „Wie bekomme ich jetzt Magento dazu, meinen Style auszuliefern?“ kamen mir seltsam bekannt vor.

Was wirklich geschah am Wochenende

Nun ja, was soll ich sagen …? Ich habe zum ersten Mal eine Pre-Party verpasst und bin erst morgens am Tag der Veranstaltung angereist. Man wird halt nicht jünger. Da ich wegen meiner Diplomarbeit letztes Jahr recht selten auf Firegento-Events war, musste man auch erstmal ordentlich netzwerken und persönlich werden. Da das aber einer der Hauptgründe für mich ist, solche Events zu besuchen, fing ich damit an. Also MacBook auf, Magento 2 laden und anfangen zu quatschen. Alibimäßig hatte ich mich deswegen auch in die Gruppe „Ist Magento 2 Mist?“ geschmissen. Das ging so den ganzen Samstag: Versuchen Magento zu installieren, quatschen über das letzte halbe Jahr, auf den Bildschirm gucken, ob die Kiste vorankommt, essen, quatschen. Zack war abends, und man saß noch in einer kleinen Runde im Brauhaus. Man ahnt es: quatschen.

Der nächste Tag sollte produktiver werden, und ich gesellte mich direkt zum Team „Migration von Firegento-PDF auf Magento 2“, dem ich samstags schon ein wenig helfen konnte.

Der Sonntag verlief dann recht flüssig mit richtiger Arbeit an Magento 2. Bis zum Versuch, die Abschlusspräsentation per Videokonferenz mit gleich zwei Ablegern des Hackathons zu halten. Am Ende gelang es irgendwie, und es ging für mich zurück nach Köln (Notiz an mich: App entwickeln, die für Events Fahrgemeinschaften erzwingt).

Schönen Dank an dieser Stelle an code-x fürs Gastgeben und an die Sponsoren!

Was ich über Magento 2 gelernt habe

Zusammenfassend lässt sich sagen: Nicht alles läuft glatt am Anfang jeder neuen Version – das ist das tägliche Brot für uns PHP-Entwickler. Ich war nicht alleine mit meinen Problemen und habe Trost und Hilfe bekommen. Da ich schon etwas tiefer in der Materie drin war, konnte ich auch selbst ein paar Mal helfen. Schönes Gefühl.

Magento 2 ist schon ein ausgereifteres Softwareprodukt als die damalige Frühversion von Magento 1 – aber aus meiner Sicht noch nicht wirklich startklar als Shop-System-Lösung für deutsche Kunden. Zudem sind bisher zu wenige Module portiert. In welchem Zeitrahmen sich das ändert, bleibt abzuwarten und zu beobachten. Die Neugierde und der Wille, mit Magento 2 zu arbeiten, war an dem Wochenende jedoch deutlich spürbar.

Der Beitrag Besuch beim Magento 2 Hackathon in Paderborn erschien zuerst auf Entwicklungshilfe NRW.