Shopware, Technik und Co.: Pflichtpraktikum Webentwicklung

Luca Matysik, Student der Medieninformatik, hat sein Pflichtpraktikum Webentwicklung bei uns in Würzburg erfolgreich hinter sich gebracht. Was er in den 6 Monaten bei der Online Rebellion erlebt hat und welche Aufgaben er eigenverantwortlich übernommen hat, erfahrt ihr in seinem umfangreichen Einblick in sein Pflichtpraktikum.

Wer sind die Rebellen? Eine kurze Einführung.

Die Agentur Online Rebellion konzentriert sich auf datengetriebenes Onlinemarketing im Bereich E-Commerce und bietet zudem individuelle Entwicklung an Shop- und CM-Systemen an. Zu meinen Aufgaben zählten daher die Installation, Ersteinrichtung und Instandhaltung der Shop- und CM-Systemen, die Entwicklung von Erweiterungen der Softwaresysteme in Form von Plugins, sowie die individuelle Gestaltung des Frontend der Systeme. Das Aufgabenspektrum umfasste jedoch noch deutlich mehr, da ich in der Rolle als Entwickler intern sowie für Kunden einer der ersten Ansprechpartner für jegliche technische Belange und Probleme war. Auch für die administrativen Bereiche wie Server und Datenbanken, Postfächer, sowie die Fehleranalyse bei bereits bestehenden Softwaresystemen war ich verantwortlich.

Projektmanagement und Methoden

Key Accounts

Je nach Fachbereich eines Projekts wurde ein dafür
zuständiger Mitarbeiter als Key-Account zugewiesen. Dieser Mitarbeiter war
verantwortlich für die externe Kommunikation mit dem Kunden und damit auch
erster Ansprechpartner. Er behielt einen Überblick zu den Projektzugehörigen Aufgaben
und managte die Zuweisung der Teilaufgaben an weitere Mitarbeiter. Als Key-Account war man für die Einhaltung des Projektaufwands in Stunden sowie die dazugehörigen Deadlines verantwortlich.

Jour Fixes (JFs)

Der Begriff Jour Fixe (kurz JF) wurde für regelmäßige Meetings genutzt. Hierbei handelte es sich beispielsweise um einen wöchentlichen Team-JF, an dem alle Mitarbeiter in einem kurzen Meeting jegliche internen Probleme, Anregungen, Einwände und Wünsche äußern konnten. Zudem wurden bevorstehende Termine, Abwesenheiten, Messen und Events angekündigt. Dieser Termin bot den Mitarbeitern auch die Möglichkeit, Fragen zu internen Unternehmensregeln, Buchung etc. im Allgemeinen zu stellen. Da der Team-JF ausschließlich für interne Unternehmensthemen war, gab es zudem fachliche JFs. Bei diesen waren meistens die Key-Accounts der dazugehörigen Projekte anwesend, um Teilprojekte zu planen oder allgemeine Fragen zu klären.

Zu guter Letzt gab es noch Einzel-JFs. Dieses Meeting fand in meinem Fall meist wöchentlich mit meinem Abteilungsführer der Entwicklung und gleichzeitig Chef der Agentur Martin Wirth statt. Der Inhalt des Termins befasste sich mit der Klärung aller Fragen meiner Teilaufgaben. Da der Fachbereich Entwicklung in beinah jedem Kundenprojekt an der ein oder ande- ren Stelle vertreten war (Wordpress/Shopware Installation, Fehleranalyse, Frontend-Änderung, technischer Support), jedoch nicht Inhalt des gesamten Projekts verkörperte, war es hilfreich und teils notwendig die Rahmenbedingungen direkt mit dem Chef zu klären. Zudem wurde hier ausführliche Hilfestellung zur Bearbeitung der Aufgaben gegeben, da die Fachkompetenz eines Praktikanten teils nicht ausreichte, um beispielsweise eine fehlerfreie Durchführung eines Updates an einem Live-Shop garantieren zu können.

Interne Kommunikationsstruktur und Tools

Im Allgemeinen waren 3 Kommunikations-Channel
für die interne Kommunikation im Einsatz:

1. Podio (CRM)
2. E-Mail
3. Telegram

Podio

Podio ist eine „Project Management and Collaboration“-Software, welche sich an einem Kanban- System orientiert. Jeder Mitarbeiter hat einen eigenen Login mit dem er sich auf der Weboberfläche einloggen kann. Neben einem Newsfeed für interne Ankündigung und einem geteilten Kalender für interne Termine und Kundenmeetings, ist es möglich sogenannte Tasks anzulegen. Jeder Task verkörpert damit eine Aufgabe, welche direkt einem Kunden und Kundenprojekt zugeordnet wird. Im Task werden dann Titel, Priorität, Deadline, Inhalt sowie der Verantwortliche definiert. Somit kann jeder Mitarbeiter alle (eigenen) Tasks übersichtlich verwalten und bearbeiten.

Eine Unternehmensregel der Online Rebellion setzt voraus, dass alle Tasks einem gewissen Schema entsprechen müssen, sodass Priorität, Inhalt, Umfang und Deadline klar definiert sind. Sobald Aufgaben nicht dem vorgeschriebenen Schema entsprachen, durften sie sofort dem Auftraggebenden zurückzugewiesen werden. Somit war man als Praktikant mit der Aufgabe nie überfordert oder im Stich gelassen und konnte im Falle auf ausführliche Unterstützung der Kollegen vertrauen. Es wurde damit jedoch auch vorausgesetzt, dass Aufgaben, welche nicht in Frage gestellt werden, vollständig verstanden wurden. Dies verlieh mir ein hohes Maß an Eigenverantwortung, meine Aufgaben auch zu hinterfragen und nach eigenem Ermessen abzuschätzen und gegebenenfalls Inhalt, Umfang und Deadline anzuzweifeln.

Ausführliche Dokumentation

Eine weitere Unternehmensregel besagte, dass alle Informationen zum aktuellen Projekt- oder Aufgabenstands ausführlich in Podio dokumentiert werden müssen, sodass keinerlei Informa- tionen beispielsweise in Gesprächen zwischen Tür und Angel verloren gehen konnten. Dies führte zu hilfreicher Transparenz des Projektfortschritts. Podio war somit das Herzstück der Agentur und bot einen schnellen Überblick der Projekte und Termine. Durch die klare Definition der Deadlines eigener Aufgaben hatte ich jederzeit einen klaren Überblick meiner zeitlichen Auslastung. Spontane Urlaubsanträge oder Fehltage auf Gleitzeit konnten somit ebenfalls ausnahmslos erteilt werden.

E-Mail

Bei Anträgen, welche nicht direkt mit internen
Podio-Tasks in Verbindung standen,
wurde auf die simple Kommunikation via E-Mail zurückgegriffen. Jeder Mitarbeiter verfügte
über ein eigenes
Postfach mit Unternehmensdomain, welches in einem Outlook- oder Thunderbird-Client
auf dem eigenen Rechner eingerichtet war.

Telegram

Als zusätzliches Kommunikationstool zur E-Mail wurden zudem einige Telegram-Gruppen angelegt. Telegram ist ein auf Handynummer basierendes Chatsystem (ähnlich zu Whatsapp), welches in der Agentur für dringende interne Ankündigungen genutzt wurde. Beispielsweise für die kurze Absprache von kurzfristigen Terminänderungen oder Notfallkom- munikation bei Server-Downs. An der Aufstellung dieser Kommunikations-Channel erkennt man meiner Meinung nach, die ausgeklügelte Struktur einer optimalen internen Kommunikation nach Dringlichkeit und unterstreicht den Ansatz eines dynamischen und flexiblen Teams.

Podio Kundenspace

Das bereits vorgestellte Projektmanagement-System Podio
hat zudem die Möglichkeit, sogenannte Kundenspaces zu erstellen. Diese
verhalten sich ähnlich wie die intern genutzte Oberfläche, ist jedoch technisch
und von der Sichtbarkeit davon getrennt. Ein Kunde kann dann mit eigenem Login seinen Kundenspace
einsehen. Alle Mitarbeiter, welche an Projekten des Kunden arbeiten, werden ebenfalls diesem Kundenspace
hinzugefügt. Nun verhält es sich so, dass im Kundenspace ebenfalls Tasks angelegt werden. Diese sind technisch
jedoch von den internen Tasks der
Online Rebellion entkoppelt. Oft besteht im Kundenspace damit nur ein Task pro Projekt (Beispielsweise Website Relaunch), welches im internen
System in viele Teilaufgaben gesplittet und den verantwortlichen Fachbereichen zugeordnet werden
(Grafikdesign für Mockups, Entwickler für eine WP-Installation, etc.). Somit hat auch der Kunde eine Übersicht
zu den aktuell bearbeiteten Projekten, jedoch keinen direkten Einblick in die
interne Kommunikation. Des Weiteren bietet
es eine Plattform
für Kunden wie auch Key-Accounts/Mitarbeiter aufkommende oder offene Fragen,
Anforderungen und Wünsche
zu klären oder zu äußern.

Ticketsystem (osTicket)

OsTicket ist ein simples open-source Ticketsystem, welches als Serverinstallation auf einem Webspace der Agentur installiert wurde. Auch hier hatte jeder Mitarbeiter einen eigenen Login für die webbasierte Oberfläche des Systems. Einige der Kontakt-Mail-Adressen der Online- Rebellion wurden als Ticket-Provider eingerichtet, sodass alle eingehenden E-Mails von Kunden oder anderer externer Personen ein Ticket eröffneten. Diese Tickets konnten dann je nach Fachbereich von den Mitarbeitern zugewiesen, bearbeitet und beantwortet werden. Nach Unternehmensregel wurde festgelegt, dass jegliche externe Kommunikation über das Ticketsystem von statten gehen musste, sodass auch hier alle Informationen zentralisiert festgehalten wurden. Somit konnten Ticketnummern beispielsweise Podio-Tasks angehängt werden, soweit externe Kommunikation für eine Aufgabe von Belang war. Für die interne Kommunikation wurde das Ticketsystem nicht genutzt.

ownCloud

Als zentraler Speicher aller Projektdaten, Bilder,
Dokumenten dient eine eigene ownCloud- Serverinstallation. Durch eine gute
Ordnerstruktur werden alle Daten in Teilbereiche der einzelnen Kunden und des
Unternehmens aufgeteilt.

Zeitbuchungen

Die Online Rebellion setzt für seine Zeitbuchungen auf ein weiteres open-source System namens Clockodo. Hier kann jeder Mitarbeiter mit eigenem Login seine Zeiten erfassen. Jedoch wird nicht einfach ein- und ausgestempelt, sondern es müssen alle Buchungen einem Kunden (oder Intern) und einer Projektleistung zugeordnet werden. Des Weiteren müssen der bearbeitete Task und eine kurze Beschreibung hinzugefügt werden. Somit erhält die Online Rebellion einen klaren Überblick über den Projektaufwand und -fortschritt, sowie die Verteilung von abrechenbaren Arbeitsstunden der Mitarbeiter. Am Ende jedes Monats werden alle relevanten Buchungen auf einen Kunden direkt auf die Rechnung gedruckt. Damit wird vollständige Transparenz für den Kunden garantiert. Das Tool bietet zudem auch für den Mitarbeiter einen guten Überblick zu bereits bearbeiteten Projekten, inklusive dessen Aufwands und hilft bei der Abschätzung nachfolgender Projektaufwände.

Fachbereich Webentwicklung

Staging Umgebungen

Für jeden unserer Kunden wurde eine sogenannte Staging-Umgebung auf dessen Webspace eingerichtet. Dies bedeutet, dass das Filesystem des Shops oder CMS des Kunden inklusive Datenbank dupliziert und per .htaccess verzeichnisgeschützt auf dem Server existierte. Somit war es mir als Entwickler möglich, jegliche Änderungen am Frontend oder Shopsystem zuerst auf einem Abbild des Livesystems vorzunehmen und zu testen, ohne den Livebetrieb zu gefährden. Gerade Frontend-Entwicklungen und Systemupdates wurden auf der Staging-Umgebung umgesetzt und anschließend ausführlich getestet, bevor dieselben Änderungen dann an der Live-Maschine vorgenommen wurden. Ein weiterer Vorteil bestand darin, dass die Änderungen vom Vorgesetzten und vom Kunden abgesegnet werden konnten, bevor sie Live deployed wurden. Die Staging-Umgebungen mussten je nach Webhoster manuell angelegt werden. Da die Live- Umgebung sich nach einiger Zeit von der Staging-Umgebung unterscheidete, mussten das Live- System in regelmäßigen Abständen neu dupliziert werden, um immer auf einer Umgebung zu entwickeln, welche dem Live-Stand am nächsten kam.

Technologien

Smarty

Smarty ist eine
für PHP entwickelte Template Engine, welche
bei Shopware zum
Einsatz kommt. Diese verfolgt
den Ansatz, das Frontend (HTML/CSS) von der Applikations-Logik zu trennen. Um es auf den Punkt zu bringen, bietet
es diverse Tags, welche
in der HTML-Struktur eingebaut
werden können, um Daten aus der Applikation einzubinden. Hierfür nutzt es
eigene Tags zum Einbinden von Variablen, welche innerhalb des Tags über sogenannte Modifier noch modifiziert werden können. Auch Schleifen oder Bedingte Operatoren könnten durch Smarty
genutzt werden. Smarty selbst
ist jedoch kein Application Development Framework oder MVC, sondern eine
Template Engine.

SCSS

SCSS ist eine Stylesheet-Sprache, mit der es möglich ist
Variablen, Schleifen, mathematische Operatoren und weitere nützliche Funktionen
zu nutzen. Grundsätzlich ist es ein CSS-Pre- Prozessor, welcher den
geschriebenen SCSS-Code letztlich in CSS umwandelt.

jQuery

jQuery ist die meistverwendete
JavaScript-Bibliothek und bietet durch eine einfachere Syntax und erweiterte Funktionen eine leichtere
Entwicklung mit JavaScript. Einer der größten
Vorteile liegt in der erleichterten Selektierung von Elementen
im DOM durch die Sizzle
Selector Engine sowie ein
besseres Event-System.

Eingesetzte Softwarelösungen / -Tools

JetBrains PhpStorm

Als Entwicklungsumgebung wurde JetBrains PhpStorm
verwendet. Durch mein Studium war mir diese IDE bereits bekannt. Neben dem
Grundsetup wurden über die integrierte Remote- Host-Funktion alle Kunden-Webspaces per FTP eingerichtet, an denen gearbeitet wurde. Somit war es
mir möglich, direkt in der IDE auf alle Serverfiles zuzugreifen. Von hier aus konnten Files in der IDE geöffnet, bearbeitet und wieder auf den Server hochgeladen werden.
Da es sich bei den Änderungen meist nur um kleine Frontend-Anpassungen
handelte, welche zuerst auf der Staging-Umgebung umgesetzt wurden, war es möglich hierbei
ohne Versionskontrolle wie Git
zu arbeiten. Alle Änderungen wurden
direkt auf dem Server umgesetzt
und getestet.

XAMPP

Mit XAMPP ist es möglich
einen lokalen Webserver schnell
und einfach aufzusetzen. Das Softwarepaket beinhaltet dabei einen Apache-Server inklusive MySQL-, PHP-
und Perl-Installation. Über ein Control-Panel können
die einzelnen Module
konfiguriert, gestartet und gestoppt werden.
Ich nutzte XAMPP für das aufsetzen einer lokalen Shopware- und Wordpress-Installation
um vollständig getrennt von unseren
Web-Servern experimentell entwickeln zu können.

Shopsystem Shopware Allgemeines

Shopware
ist ein seit 2004 in Deutschland entwickeltes open-source Online-Shopsystem.
Gerade in Deutschland ist Shopware einer der Spitzenreiter im Bereich E-Commerce-Softwarelösungen für kleine
und mittelständische Unternehmen.

Modularität durch Plugin Store

Es verfügt über einen Plugin-Store welcher von diversen
Agenturen, Entwicklern, Freelancern usw. befüllt wird. Dadurch ist das Shopsystem sehr modular, da jegliche Erweiterungswünsche oft bereits in Plugins
verpackt im Store zur Verfügung stehen.
Zwar sind diese zu erwerben, jedoch oft billiger, als eine Agentur individuell
daran arbeiten zu lassen.

Installation und Einrichtung

Eine der wichtigsten Aufgabenbereiche meines Praktikums, war der Umgang mit Shopware. Dies begann bereits bei der Installation eines Systems auf einem von uns gemieteten Webspaces. Die Installation erfolgt durch das anlegen einer Datenbank, entpacken des File-Systems auf dem Server und anschließender Installation geführt durch einen Installations-Wizard im Browser. Nach erfolgreicher Installation kann das Control-Panel (auch genannt Backend) des Shops bereits vollständig bedient werden. Der Shop wird mit Demo-Daten angelegt, welche nun abhängig des Kunden angepasst werden. Zahlungsarten sowie Lieferzeiten müssen korrekt konfiguriert werden. Des Weiteren können bereits diverse Shopseiten wie Rechtliches (Datenschutz, Impressum, AGBs, Widerrufsbelehrung) oder Informatives (Über uns, Kontaktformular) eingerichtet werden. Je nach Kunde, wurde die Einrichtung des Shops vom Fachbereich Entwicklung übernommen und anschließend an den Kunden kommuniziert, sodass dieser mit der Einpflege der Artikeldaten beginnen konnte.

Frontend-Entwicklung

Das Frontend in Shopware basiert auf einem speziellen Parent-Child-Templating System. Im Wesentlichen existieren von Anfang an bereits das Bare-Theme und Responsive-Theme. Im Bare-Theme sind bereits alle Template-Dateien vorhanden, um den Shop in einer voll funktionsfähigen Demo-Version darzustellen. Das Responsive-Theme leitet von Bare-Theme ab und erweitert es um ein responsives Styling. Das bedeutet, dass alle Template-Dateien, welche das Responsive-Theme nicht explizit überschreibt, vom Bare-Theme geerbt werden. Um nun eigene Anpassungen am Frontend vorzunehmen, muss ein neues Child-Theme erstellt werden, welches nun vom Responsive-Theme (Parent-Theme) ableitet. Sobald dies gemacht wurde, können die Template-Dateien des Bare- oder Responsive-Themes überschrieben werden. Um ein Template nicht vollkommen neu schreiben zu müssen, sind logisch zusammenhängende HTML-Snippets in den Template-Dateien in Blöcke geklammert:

{block name=xy} <html content> {/block}

Anhand des Blocknamens können nun auch nur einzelne Blöcke eines Templates im eigenen Theme überschrieben werden. Somit kann ein Großteil des Shopware-Standards beibehalten werden und nur an den Stellen angesetzt werden, welche angepasst werden sollen. Alle Template-Dateien eines Themes sind in Shopware auf File-Ebene in einem Theme-Ordner enthalten. Dieser Ordner hat mehrere Unterordner, in denen alle Template-Dateien nach ihrem Controller sortiert sind. Beispielsweise der Ordner „Checkout“, welcher alle Template-Dateien enthält, welche im Checkout im Content-Bereich der Seite (zwischen Header und Footer) angezeigt werden können. Möchte man also beispielsweise den Aufbau einer Checkoutseite ändern, so muss im eigenen Theme-Ordner zuerst der Unterordner „Checkout“ angelegt werden und darin die zu ändernde Template-Datei. In dieser Datei kann der zu ändernde Block über den Namen angesprochen und überschriebene werden. Es ist wichtig, dass der Ordnerpfad und die Namensgebung der eigenen Template-Dateien identisch zum Bare-Theme angelegt werden.

Chancen und Einschränkungen

Aus meiner Erfahrung als Webentwickler bei der Online Rebellion, ist dieses Templating-System nur für kleine Frontend-Änderungen sinnvoll. Es kann in kürzester Zeit einzelne Bausteine des Templates angepasst werden. Jedoch wird einem schnell bewusst, dass größere Anpassungen zu teils ein Ding der Unmöglichkeit werden. Ein gutes Beispiel hierfür ist, dass Plugins von Drittanbietern ebenfalls das Templating-System nutzen und demnach Blocks überschreiben, um sie anzupassen oder zu erweitern. Die Hierarchie der Vererbung prozessiert jedoch eigene Änderungen nach den Plugin-Änderungen. Sobald man daher im eigenen Theme einen Block überschreibt, welcher von einem Plugin ebenfalls bearbeitet wurde, werden auch die Änderungen des Plugins überschrieben. Dies führt dazu, dass der Aufbau einiger Blocks aus dem Bare-Theme nicht überschrieben werden können, da sonst die Änderungen durch Plugins verloren gehen. Demnach kann der Shop nicht vollständig individualisiert werden, sondern gibt bereits ein ziemlich festes Grundgerüst vor.

Mailchimp

Mailchimp ist eine umfangreiche von einem amerikanischen Unternehmen entwickelte Softwarelösung für den Versand von Newslettern. Es bietet die Möglichkeit seine Subscriber extern von anderen Systemen wie Beispielsweise Shopware zu verwalten und mit Newsletter- Kampagnen zu bespielen. Es können verschiedene Listen angelegt und Subscriber per CSV- Tabellen oder über REST-API hinzugefügt werden. Danach können alle Subscriber verwaltet, kategorisiert und mit beliebigen Datensätzen erweitert werden. In einem modularen und sehr simplen Drag&Drop-Editor kann nun ein E-Mail-Template erstellt werden. Man hat die Auswahl zwischen diversen Elementen wie Countdowns, Bildern, Texten sowie auch Variablen, welche beim ausspielen mit Datensätzen des Subscribers ersetzt werden. Gerade für den Gebrauch im E-Commerce besteht die Möglichkeit Gutscheincode-Elemente und sogar Artikel-Elemente einzubauen, welche direkt vom Shopsystem importiert werden.

Kampagnen-Mails

Nach dem Erstellen einer E-Mail, kann diese über eine Kampagne verschickt werden. Durch die verschiedene Kategorisierung und Segmentierung der Subscriber, kann explizit konfiguriert werden, für welche Subscriber einer Liste welche E-Mail-Templates genutzt werden sollen. Man hat voll Kontrolle über den Versandzeitpunkt und kann eine Kampagne auch in einzelnen Paketen versenden, um eine Shopserver-Überlastung vorzubeugen. Um verschiedene E-Mail-Templates zu testen, können auch A-B-Test in den ersten Paketen versandt werden, um abhängig des Erfolgs der verschiedenen Templates das Bessere für den Rest der Kampagne zu nutzen. Neben den Kampagnen können zudem sogenannte Trigger angelegt werden. Diese sind auf ein bestimmtes Ereignis oder einen Datensatz programmiert.

Personifiziertes Mailing für Stammkunden

Als einfachstes Beispiel der Geburtstagsnewsletter. Soweit die Information als Datensatz in der Liste besteht, kann ein Trigger angelegt werden, der jeden Tag prüft, ob Subscriber Geburtstag haben. Sollte dies der Fall sein, versendet Mailchimp an diese Subscriber ein definiertes E-Mail-Template. Neben dem Versand von Newslettern bietet das Tool zudem eine ausführliche Statistik von Kampagnen- und Trigger-Mails. Öffnungsraten, Umsätze, sowie auch Klickdaten innerhalb der E-Mail werden erkannt und in der Statistik dargestellt. Viele Shopsysteme, darunter auch Shopware, verfügen über extra Plugins für die Übertragung von Newsletter- und Bestandskunden-Daten nach Mailchimp. Da Mailchimp über eine gut dokumentierte REST-API verfügt, wurden diese Plugins von Drittanbietern entwickelt und wie reguläre Plugins im Plugin-Store von Shopware angeboten.

IT-Recht-Kanzlei

IT-Recht-Kanzlei ist eine Münchner Kanzlei, welche sich auf Rechtstexte im E-Commerce spezialisiert hat. Die Kanzlei verfügt über ein Webportal, auf dem verschiedene Pakete gebucht werden können. Sobald ein Paket gebucht wurde, können Rechtstexte wie AGBs, Impressum, Datenschutzerklärungen sowie Widerrufsbelehrungen über ein Checkbox-System zusammengeklickt werden. Nach Auswahl der zutreffenden Punkte auf den eigenen Shop, werden automatisch die passenden Rechtstexte generiert. Es besteht sogar die Möglichkeit einige Shopsysteme, darunter auch Shopware, über ein Shopsystem-Plugin anzubinden. Sollten sich danach Textpassagen ändern, werden diese automatisch an den Shop übertragen und auf der entsprechenden Shopseite eingefügt. Gerade für kleinere und mittlere Unternehmen des E-Commerce ist dies, meiner Meinung nach, die perfekte Lösung.

Pflichtpraktikum Webentwicklung: Aktuelle Projekte

Hauptsächlich beschäftigte ich mich in meiner Zeit als Praktikant mit der Betreuung unserer Shopware-Kunden. In den ersten Wochen lernte ich das Shopsystem selbst kennen und las mir eine Menge Fachwissen zur Einrichtung, Konfigurationen und Verwaltung an. Mit diesem Wissen konnte ich unseren Kunden beim Großteil aller Anliegen weiterhelfen. Sei es beispielsweise das Anlegen neuer Versandkosten oder Zahlungsarten, so konnte ich mich ins Shop-System des Kunden einloggen und diese nach dessen Wunsch konfigurieren. Jedoch auch bei technischen Problemen, war ich einer der ersten Ansprechpartner. Bei langen Ladezeiten musste ich die Serverauslastung sowie das Caching überprüfen, um danach meinem Chef einen Überblick und Ansätze zur Lösung des Problems vorzulegen.

Installation von Plugins

Ein weiteres immer wiederkehrendes
Anliegen unserer Kunden, war die Installation von Shopware-Plugins aus dem
Plugin-Store. Wie bereits
beschrieben, fasst der Plugin-Store eine Vielzahl an Shop-Erweiterungen von Dritt-Entwicklern,
welche ihre Plugins dort kommerziell anbieten. Besondere Zahlungsarten wie
Paypal und Klarna, oder ERP-Erweiterungen werden ebenfalls als Plugins im Store angeboten. Es kann durchaus sein, dass
Shopsysteme oder bereits installierte Plugins mit anderen Plugins nicht
kompatibel sind und damit zu einem System-Crash oder zu Frontend-Problemen
führen könnten. Um dies auf Live-Umgebungen zu vermeiden, testete
ich alle zu installierenden Plug- ins immer zuerst auf einer Staging-Umgebung.
Da dies und die potenziellen Fehlermeldungen
in den meisten Fällen die Kompetenz unserer
Kunden überschritt, war dies ebenfalls Teil meines Aufgabenbereichs.

Shopsystem-Umzug für einen Kunden

Eines meiner größten Projekte war der Relaunch eines Kunden, welcher vom Shopsystem Gambio auf Shopware umzog. Aufgrund der hauptsächlich technischen Aufgaben des Projekts, wurde ich als Key-Account des Kunden ausgewählt und war damit erster Ansprechpartner. Der Kunde hatte ein eher kleines Sortiment an Lebensmitteln, welche er selbst herstellte. Erster Schritt des Projekts war das aufsetzen einer neuen Shopware-Installation. Danach wurden die Content-Seiten soweit wie möglich im neuen Shopsystem eingepflegt. Ich installierte die Zahlungsarten Paypal und AmazonPay und richtete Versandkosten für deutschlandweiten und europäischen Versand ein.

Da der Gambio-Shop bereits einige Jahre in Betrieb war, war bereits ein großer Kundenstamm vorhanden, welcher nicht verloren gehen sollte. Deshalb migrierte ich alle Kundendaten ins neue Shopsystem. Dafür exportierte ich die entsprechenden Datenbanken-Tabellen im CSV- Format und erstellte damit eine weitere CSV-Datei welche dem Import-Schema von Shopware entsprach. Über ein Import-Modul von Shopware konnte ich dann alle Kundendaten und deren Lieferadressen ins neue Shopsystem migrieren. Nach erfolgreichem Import des Kundenstammes, waren die Artikel der nächste Schritt. Auch hier konnte gebrauch vom Import-Modul von Shopware gemacht werden. Ich generierte eine CSV-Tabelle, welche dem Artikel-Import-Schema entsprach und fügte einige Beispiel-Produkte ein. Danach schrieb ich eine kurze Anleitung und leitete es dem Kunden weiter, sodass dieser seine Produkte in die Liste einpflegen konnte.

Shop rechtssicher machen

Ein weiterer wichtiger Punkt waren neue Rechtstexte. Dafür nutzten wir die Dienste der IT- Recht-Kanzlei. Ich konfigurierte die Rechtstexte, installierte das zugehörige Shopware-Plugin und startete die Live-Synchronisation. Mithilfe der Einkaufswelten gestaltete ich eine neue Startseite für alle Viewports. An der ein oder anderen Stelle passte ich zudem die Frontend- Templates an, um beispielsweise Shopware-Logos zu entfernen oder den Footer abweichend vom Standard darzustellen. Nachdem der neue Shop aus Content und technischer Sicht in einem vollständigen Zustand war, vereinbarte ich einen Termin mit dem Kunden in unserem Office in Würzburg. An diesem Termin stellte ich ihm den neuen Shop vor. Dies beinhaltete das Frontend sowie auch die Bedienung des Control-Panels von Shopware. Ich erklärte ihm die wichtigsten Funktionen und wie er nach dem Live-Gang neue Bestellungen abzuarbeiten hat.

Artikelimport und Fertigstellung des Shop-Systems

Danach importierten wir die von ihm vervollständigte Artikel-CSV und überprüften ob alle Daten vorhanden waren und wie er seine Artikel nun über das Control-Panel weiterpflegen kann. Nach dem Artikelimport war der Shop damit vollständig und wartete nur noch auf den Live- Gang. Für den Go-Live-Prozess wurden zudem alle URLs des alten Shops in der htaccess-Datei des Shopware-Systems auf die neuen URLs weitergeleitet. Danach musste nur noch die Domain umgestellt werden und der Shop war Live. In den folgenden Wochen leistete ich weiterhin Support zur Bedienung des Shopsystems und passte weitere Shopeinstellungen nach Wünschen des Kunden an.

Kunden-Website: UI-Relaunch

Ein weiteres großes Projekt in meiner Praktikumszeit war der UI-Relaunch eines bereits bestehenden Shopware-Shops. Dieser nutzte seit vielen Jahren nur das Standard-Theme von Shopware. Da der Shop jedoch derartige Besucher- und Umsatzzahlen verzeichnen konnte, wollte der Kunde sich vom Standard abheben und die Shop-Oberfläche professioneller und vor allem individueller gestalten lassen, um das Shopping-Erlebnis und die User-Experience grundlegend zu verbessern.

Grundlegende Strukturen

Zu Beginn designte unsere Grafik- und Webdesignerin Mockups für die essenziellsten Shop- Seiten. Dies beinhaltete die Startseite, das Kategorie-Listing, die Produktdetailseite, den Login- und Registrierungs-Prozess sowie den Checkout-Prozess. An dem Projekt, welches auf einer Staging-Umgebung entwickelt wurde, waren 4 Entwickler für 2 Wochen beschäftigt, um alle Mockups in Template-Änderungen umzusetzen. Ich selbst war allein für den Login- und Registrierungs-Prozess, die Startseite und den Checkout-Prozess verantwortlich. Zur Vorbereitung wurde in einem Termin die Mockups mit der Webdesignerin und unserem Chef Martin Wirth besprochen. Besonders wichtig hierbei war, Elemente der Mockups anzusprechen, bei denen wir Schwierigkeiten bei der Umsetzung sahen. Da das Templating-System von Shopware die Änderung am Grundaufbau der HTML-Struktur einschränkt, mussten auch an den Mockups die ein oder anderen Änderungen vorgenommen werden.

Nach dem Termin besprachen die Entwickler den ungefähren Projektplan sowie die Aufteilung der einzelnen Aufgaben. Da viele Elemente wie Buttons oder Überschriften auf allen Seiten genutzt wurden, beschlossen wir alle globalen Styles zu definieren und bereits auf der Staging- Umgebung umzusetzen. Danach konnte jeder Entwickler mit seinem Teilprojekt beginnen. Wir kommunizierten hauptsächlich über Telegram, um noch fehlende globale Styles anzumerken. Diese wurden dann im dazugehörigen Podio-Task vermerkt und umgesetzt.

Webentwicklung: Umsetung des Mockups

Ich begann mit der Entwicklung des Checkout-Prozesses, da mir dessen Umsetzung am schwierigsten vorkam. Der Prozess beinhaltete insgesamt 4 Seiten. Die Warenkorbübersicht, die Zahlungsartenauswahl, die Bestätigungsseite und zuletzt die Zielseite welche nach einer erfolgreichen Bestellung angezeigt werden sollte. Alle Seiten waren im Shopware-Standard bereits vorhanden, demnach musste hauptsächlich das Styling und teilweise die HTML-Struktur des Standards überschrieben werden.

Während der Entwicklung, bemerkte ich zeitig, dass einige Elemente des Mockups nicht umgesetzt werden konnten, da viele Plugins ebenfalls die Templates veränderten und ich diese Änderungen nicht überschreiben durfte. Das grundsätzliche Problem zum Templating bei Shopware habe ich bereits unter 4.4.3 beschrieben. Ich orientierte mich demnach stark am Standard-Aufbau und versuchte, in erster Linie über das Styling das Mockup umzusetzen. Nach dem Checkout änderte ich die Darstellung des Login- und Registrierungsprozesses. Dafür gab es eine Seite, welche beide Formulare anzeigte. Da hier keine Plugins Änderungen vornahmen, konnte ich auch die HTML-Struktur nach belieben umschreiben. Ich programmierte ein Drop-Down für die Registrierungsformulare mithilfe von JavaScript (jQuery) und konnte das Mockup 1:1 umsetzen.

Neues Design für Startseite

Als letztes Teilprojekt gestaltete ich die Startseite von Grund auf neu. Hierfür nutzte ich die Einkaufswelten sowie ein Plugin, mit dem ich einzelne Einkaufswelten-Elemente noch vielseitiger designen konnte. Einige Elemente musste ich trotzdem als Code-Element einbauen und die HTML-Struktur sowie Styling selbst schreiben. Nach einer Woche präsentierten wir unserem Chef und der Webdesignerin in einem Termin unseren bisherigen Projektstand. Hier gingen wir wieder auf Schwierigkeiten ein und an welchen Stellen wir Kompromisse mit dem Mockup eingehen mussten und noch werden. Den Zeitraum von 2 Wochen konnten wir letztlich einhalten und konnten eine Woche später einen finalen Stand vorstellen, welcher die essenziellsten Änderungen der Mockups enthielt. Ich definierte zudem alle Schritte, welche für den Go-Live-Prozess nötig waren und legte diese meinem Chef vor, da ich aufgrund meines zeitnahen Praktikumsende nicht mehr am Live-Gang beteiligt sein konnte.

Pflichtpraktikum Webentwicklung: Fazit Kundenprojekt

Insgesamt war ich mit dem Projekt zufrieden. Als
Entwickler hatte ich eine hohe Eigenverantwortung für meine Teilprojekte und hatte zudem
selbstständig Entscheidungen zu Mockup-Abweichungen zu treffen und zu rechtfertigen. Die einzige Kritik,
die ich am Projekt anmerken konnte, waren die Mockups.
Meiner Meinung nach wäre es sinnvoller gewesen, die Mockups zusammen mit einem Shopware-Entwickler zu gestalten. Damit hätte man sich diverse
Diskussionen zur Umsetzbarkeit von einigen Elementen sparen können.
Shopware ist sicherlich kein perfektes Shopsystem, um vollständig individuell daran entwickeln zu können, da zu viele Plugins
nur mit standardnahen Themes kompatibel sind. Trotzdem ist man auf die meisten
dieser Plugins angewiesen, wie beispielsweise die der Zahlungsarten Paypal und AmazonPay.

Shopware-Updates

Shopware veröffentlichte in relativ regelmäßigen Abständen Shop-System-Updates. Diese beinhalteten Bugfixes und Sicherheitsupdates, aber auch neue Features. Aufgrund dessen, boten wir unseren Kunden nach ca. 1 – 3 neuen Releases (ungefähr 1 Release pro Monat) an, ein Update des Shopsystems durchzuführen. Auch hier wurde das Update zuerst auf der Staging-Umgebung durchgeführt, um mögliche Komplikationen oder Inkompatibilitäten auf der Test-Umgebung zu entdecken. Danach musste der Live-Shop für bis zu einer Stunde in Wartungs- modus gewechselt werden. Im E-Commerce waren die besten Zeiten dafür früh morgens in der Mitte der Woche.

Ablauf Updateprozess

Zuerst musste geprüft werden, ob eine funktionstüchtiges File-System-Backup vorlag, welches nicht älter als eine Woche war. War dies nicht der Fall, musste dies zuerst über das Control-Panel des Servers angelegt werden. Danach wurde die Datenbank exportiert und auf dem Server sowie lokal gesichert. Kurz nach dem sichern der Datenbank, wurde der Webshop in den Wartungsmodus gestellt, um neue Bestellungen und damit Änderungen der Datenbank zu verhindern. Im Wartungsmodus mussten nun alle Plugins auf die neuste Version geupdatet werden. Bereits hier konnte es oft zu Problemen kommen, da Plugins beim Update, ähnlich wie bei der Installation, manchmal zu Systemfehlern oder Frontend-Problemen führen konnten.

Nach Update der Plugins konnte dann das Shopsystem-Update über einen Wizard im Control-Panels des Shops gestartet werden. Über den Browser konnte man dann den Verlauf des Updates mitverfolgen. In den meisten Fällen liefen die Updates problemlos durch. Falls es doch zu Fehlern kam, konnten diese im Updateverlauf gefunden und gelöst werden. Nach dem Update musste nur noch der Cache gelöscht, der Wartungsmodus entfernt und der Erfolg dem Kunden kommuniziert werden.

Einkaufswelten

Shopware bietet von Haus aus einen Drag&Drop Editor namens „Einkaufswelten“ für Content- Seiten und Startseiten an. In diesem Editor können Text-, Bild-, Artikel-, Blog- und Code- Elemente in einem Gridlayout angeordnet und konfiguriert werden. Alle unserer Kunden, nutzten die Einkaufswelten mindestens für ihre Startseite. Im Zuge unserer Coversion-Optimierungen, baute ich diese Startseiten bei vielen unserer Kunden neu auf. Dazu erhielt ich ein Mock-Up unserer Grafik- und Webdesignerin und versuchte, soviel wie möglich davon umzusetzen.

Oft waren Elemente angedacht, welche nicht direkt von Shopware im Standard zur Verfügung standen, wie zum Beispiel ein Newsletter-Anmeldeformular. Hierfür durfte ich dann ein Code-Element im Grid platzieren, um darin den entsprechenden HTML-Code zu schreiben und per SCSS zu stylen. Es gab weitere Text-Bild-Kombinationen im Mockup, welche zwar einfach als Bild umgesetzt hätten werden können, jedoch dann aus SEO-Sicht keinen Wert gehabt hätten. Auch diese Elemente setzte ich in einem Code-Element um, da Shopware standardmäßig nur Text- oder Bild-Elemente zur Verfügung stellte.

Ein weiterer großer Faktor war die Responsivität der Einkaufswelten. Das Gridlayout hatte verschiedene Verhaltensweisen, welche konfiguriert werden mussten. Je nachdem mussten alle Elemente jeweils für die verschiedenen Viewports angeordnet werden. Die Einkaufswelten waren zwar bis zu einem bestimmten Grad relativ gut von Shopbetreibern ohne weitere programmatische Fachkenntnisse bedienbar. Jedoch konnten viele individuelle Elemente und einwandfreie Responsivität erst durch einen Entwickler gewährleistet werden.

Plugin-Entwicklung

Gerade bei den Einkaufswelten erkannte ich viel Potential, diese um weitere individuelle Elemente zu erweitern. Deshalb beschloss ich, mich mit der Plugin-Entwicklung auseinander zu setzen, um neue Elemente über ein Plugin hinzufügen zu können. Shopware besitzt eine gute Entwickler-Dokumentation, bei der ich schnell fündig wurde, wie ein eigenes Einkaufswelt-Element als Plugin verpackt werden konnte. Ich downloadete mir ein Sample-Plugin und analysierte alle Files solange, bis ich ihre Funktion und die Zusammenhänge verstanden hatte. Mein Ziel war es ein Plugin für ein Einkaufswelten-Element zu entwickeln, welches es dem Nutzer ermöglichte, Text auf einem Hintergrundbild darzustellen.

Deshalb definierte ich im Plugin die Felder für den Text und das Bild, welche in der Konfiguration des Elements angezeigt werden sollten. Zusätzlich fügte ich Radio-Buttons hinzu, mit denen die Ausrichtung und Position des Hintergrundbildes ausgewählt werden konnten. Somit konnte nach Installation des Plugins bereits das Element in das Grid platziert werden und über die Element-Konfiguration konnten der Text, das Hintergrundbild sowie dessen Styling eingestellt werden. Was nun nur noch fehlte war das HTML-Layout, indem die Werte der Konfigurationsfelder dargestellt werden sollten. Demnach entwickelte ich eine simple HTML-Struktur, in der ich die Werte der Felder als Variablen einbauen konnte. Somit war das erste eigene Shopware-Plugin entwickelt und ist seither im Live-Betrieb bei einiger unserer Kunden im Einsatz.

Was nun nur noch fehlte war das HTML-Layout, indem die Werte der Konfigurationsfelder dargestellt werden sollten. Demnach entwickelte ich eine simple HTML-Struktur, in der ich die Werte der Felder als Variablen einbauen konnte. Somit war das erste eigene Shopware-Plugin entwickelt und ist seither im Live-Betrieb bei einiger unserer Kunden im Einsatz.

Export an Lager & Versand Fulfillment

Ein weiteres Tool an dem ich in meiner Praktikumszeit arbeiten durfte, war ein in PHP geschriebenes Export-Skript. Da viele unserer Kunden den Pack- und Versandprozess an einen externen Dienstleister auslagerten, mussten die Bestellungen vom Shopsystem Shopware an den Dienstleister übermittelt werden. Da es dafür keine Erweiterung im Shopware-Pluginstore gab, wurde inhouse ein Skript entwickelt, welches über einen Cronjobaufruf automatisch in regelmäßigen Abständen die Bestell-Daten an den Dienstleister per Mail übermittelt. Das Skript und die Grundfunktionalität war bereits vorhanden, jedoch optimierte und erweiterte ich den Code. Im Grunde nutzte das Skript die REST-API von Showpare. Über einen API-User und -Key konnten diverse Routes angesprochen werden, um Daten in Form von JSON-Objekten anzufragen oder über Post/Put-Requests zu verändern.

Zu Beginn des Skripts wurden alle Bestellungen angefragt, welche den Bestellstatus „Offen“ hatten. Neue Bestellungen werden mit diesem Status angelegt und wurden demnach noch nicht versandt oder anders bearbeitet. Aus dem Ergebnis wurden nun alle Bestellungen gefiltert, welche bereits bezahlt wurden, oder dessen Zahlungsart „auf Rechnung“ war. Zudem mussten alle „Amazon FBA“-Bestellungen entfernt werden, da diese direkt von Amazon versendet werden. Da jedes Bestellungs-Objekt auch die wichtigsten Kundendaten enthielt, mussten diese nicht extra angefragt werden. Somit waren alle essenziellen Daten für den Versand-Dienstleister vorhanden. Diese Daten mussten nun nur noch in ein XML-Schema transformiert und in einer Datei gespeichert werden. Das XML-Schema wurde uns vom Dienstleister vorgegeben, sodass diese die Files direkt in ihr System hochladen konnten. Die Files wurden dann über einen PHP- Mailer und der SMTP-Konfiguration an den Dienstleister versandt.

Mailchimp Einrichtung mit Shopware

Wie bereits erwähnt, existieren Shopware-Plugins, welche
Newsletter-, Bestandskunden- und E-Commerce-Daten an das Newsletter-Tool
„Mailchimp“ exportieren. Dieser Export ist in 3 verschiedene Plugins
unterteilt.

• Shopware selbst bietet standardmäßig ebenfalls ein Newsletter-Modul, welches jedoch von der Funktionalität mager ausfällt. Viele unserer Kunden hatten jedoch vor dem Umstieg auf Mailchimp bereits einige Subscriber in Shopware angesammelt. Das erste Plugin exportierte demnach alle bereits bestehenden Newsletter-Subscriber aus Shopware an Mailchimp. Der Export wurde über einen Cronjob täglich ausgeführt. Demnach konnte die Anmeldung zum Newsletter auch weiterhin über das Standard-Shopware-Formular genutzt werden, da alle Shopware-Newsletter-Subscriber regelmäßig über das Plugin an Mailchimp übertragen wurden. Sobald Mailchimp vollständig eingerichtet wurde und alle bisherigen Newsletter-Subscriber übertragen wurden, ersetzte ich jedoch das Shopware-Formular mit einem Mailchimp-Formular, welches Neuanmeldungen direkt in Mailchimp eintrug. Dadurch konnte der Double-Optin-Prozess ebenfalls über Mailchimp gesteuert werden, was deutlich schneller als bei Shopware funktionierte. Zudem konnte eine Hinweis-Seite zum Double-Optin individuell über Mailchimp dargestellt und gestaltet werden.

• Das zweite Plugin exportierte alle Bestandskunden- und E-Commerce-Daten. Das bedeutet, dass über einen Cronjob in regelmäßigen Abständen alle Bestandskunden, deren Bestellhistorie, alle Produkte sowie aktive Gutscheincodes übermittelt wurden. Wie bereits beschrieben, konnten die exportierten Produkt- und Gutscheindaten dann in einem Newsletter-Template direkt eingefügt werden. Zudem hatte man eine Liste aller Bestandskunden zur Verfügung, denen man ebenfalls Newsletter verschicken konnte.

• Das letzte Plugin beschäftigte sich nur mit der Ergänzung von Kundendaten in der Subscriber- Liste von Mailchimp. Hier konnten zusätzliche Kundendaten-Felder aus Shopware neuen Datenfelder in den Mailchimp-Listen zugeordnet und übertragen werden. Beispielsweise das Feld des Geburtsdatums oder der Sprache eines Kunden war nicht standardmäßig im Export des zweiten Plugins enthalten und konnte damit nachgepflegt werden.

Plugin-Einstellungen vornehmen

Die Einrichtung der Plugins umfasste damit die Installation der Plugins im Shopsystem, sowie das Konfigurieren der Listen-APIs. Nachdem die Verbindung gewährleistet war, mussten nur noch diverse Plugin-Einstellungen getätigt werden. Beispielsweise ob Mailchimp oder Shopware den Double-Optin übernimmt, damit ein Kunde nach der Anmeldung nicht 2 E-Mails zur Bestätigung der Newsletter-Anmeldung bekam Feedback Mailing in Mailchimp. Für die Kundenanfragen durch den hauseigenen Shop ISYbe der Online Rebellion kam ebenfalls das Ticketsystem osTicket zum Einsatz, um die Anfragen übersichtlich verwalten und beantworten zu können. Ein Feature, welches osTicket jedoch nicht mitbrachte, war eine automatische Feedback-Rückfrage, sobald ein Ticket geschlossen wurde. Hierfür erarbeitete und programmierte ich eine Lösung, um die Kundendaten eines geschlossenen Tickets an Mailchimp zu übermitteln, damit darüber eine Feedback-Mail an den Kunden verschickt werden konnte. Ich programmierte dafür ein PHP-Skript, welches täglich alle geschlossenen Tickets des Vortages aus der Datenbank auslas.

Aus den Daten der Tickets konnte danach die E-Mail-Adresse des Kunden ermittelt werden. Da Mailchimp bereits alle Kunden über die Plugins in einer Liste gespeichert hatte, nutzte ich die Mailchimp-REST-API um den Subscribern anhand der ermittelten E-Mail-Adressen der geschlossenen Tickets das Datum des Statuswechsels zu „Geschlossen“ in ein neues Datenfeld einzutragen. Somit erhielt jeder Kunde, welcher am Vortag ein Ticket geschlossen hatte, einen Timestamp in der Mailchimp-Liste. Anhand davon konnte nun ein Trigger in Mailchimp eingerichtet werden, der allen Kunden eine Feedback-Mail schickte, wenn der Timestamp genau 3 Tage zurück lag.

Kategorisierung von Bestandskunden in Mailchimp

In Mailchimp ist es möglich, Subscriber einer Liste in Segmente zu unterteilen indem man ihnen Tags zuweist. Diese Tags können nach Wunsch erstellt und mehreren Subscribern zugeteilt werden.Leider brachten die Shopware-Plugins keine Funktion mit sich, um Bestandskunden abhängig von deren Einkäufen automatisch Tags zuzuweisen. Die Idee war jedoch, Bestandskunden durch Tags zu segmentieren, in welchen Kategorien sie bereits eingekauft hatten, um Newsletter spezifisch an Interessenten einer bestimmen Kategorie verschicken zu können. Hierfür entwickelte ich ein PHP-Skript, welches mithilfe der Mailchimp-REST-API für alle Bestandskunden die Kategorien der bereits gekauften Produkte in Shopware als Tags in der Mailchimp-Liste anlegte und den Subscribern zuordnete. Dafür programmierte ich einen komplexen SQL-Query, welcher mir alle Kategorien zugeordnet zu den E-Mail-Adressen der Kunden zurücklieferte. Anhand daran entwickelte ich eine Schleife, welche die Post-Requests für die Mailchimp-REST-API in 500er-Batches generierte. Diese Batches wurden danach durch einen API-Client an Mailchimp gesendet und abgearbeitet. Danach hatten alle Subscriber der Bestandskunden-Liste Tags zugewiesen, welche für die Kategorien der gekauften Produkte stand. Durch diese Tags konnten die Subscriber dann nach belieben segmentiert werden, sodass beispielsweise ein Newsletter nur an die Subscriber verschickt wurde, welche bereits in Kategorie XY eingekauft hatten.

Bestellungen zusammenführen

Ein weiteres Skript, das ich entwickeln durfte, fügte noch offene Bestellungen des gleichen Kunden bei ISYBE zu einer Bestellung zusammen. Dies war dazu da, um Teillieferungen und Versandkosten einzusparen. Es kam einige Male vor, dass ein Kunde mehrere Bestellungen machte, bevor die Daten an den Versanddienstleister übermittelt wurde. In dieser Zeit konnten die Bestellungen demnach noch zusammengeführt werden. Hierfür nutzte ich die Shopware-REST-API um alle noch relevanten und offenen Bestellungen anzufragen. Danach verglich ich die Kunden der Bestellungen einmal nach der Kunden-ID und nach der Lieferadresse. Stimmten diese überein, so legte ich eine neue Bestellung über einen Post-Request an, welche die Positionen der übereinstimmenden Bestellungen enthielt. Danach setzte ich den Status der Teil-Bestellungen auf „storniert“, um den Export an den Versanddienstleister zu verhindern.

Pflichtpraktikum Webentwicklung bei Online Rebellion: Ein abschließendes Fazit

Insgesamt hat mir meine Zeit während meines Pflichtpraktikums Webentwicklung bei der Online Rebellion sehr gefallen. Die Philosophie, Atmosphäre und Zusammenhalt der Agentur sind einzigartig und unterscheiden sich im positiven deutlich von allen bisherigen Berufserfahrungen in größeren Unternehmen und Konzernen. Die Arbeitsweise und der Umgang miteinander motivierten mich im gesamten Zeitraum meines Praktikums und halfen mir mich gänzlich wohlzufühlen. Zwar hatte ich wenige Großprojekte mit komplexem Entwicklungsaufwand, jedoch konnte ich dadurch deutlich mehr Erfahrung in vielen anderen Teilbereichen sammeln. Gerade im Bereich Entwicklung konnte ich meine bereits fortgeschrittenen Kenntnisse in der grundlegenden Frontend-Entwicklung mit HTML, CSS und JavaScript perfektionieren. Ich lernte im Bereich Server und Administratives einen ausführlichen Umgang mit Webspaces, deren Konfigurationen und Möglichkeiten diese bei Fehlern zu debuggen. Zudem lernte ich diverse Softwarelösungen auf File-Ebene kennen. Die Installation der Systeme osTicket, Wordpress, ownCloud und Shopware ermöglichten mir, bereits bestehende Softwaresysteme zu untersuchen und davon zu lernen. Besonders die Datenbank-Modelle gaben mir ein gutes Verständnis davon, wie große Systeme aussehen können und wie diese aufgebaut sind.

Aus Fehlern lernen

Leider durfte ich in meiner Zeit als Praktikant auch das ein oder andere Mal die Sensibilität von Files auf einem Server erfahren. Ich konnte es nicht vermeiden durch Änderungen auf File- oder Datenbank-Ebene eine Website zu crashen. Für mich war dies trotzdem eine der wertvollsten Erfahrungen, da ich lernte, dass Änderungen, welche auf den ersten Blick nicht riskant erscheinen, trotzdem große Auswirkungen haben können und daher immer hinterfragt werden müssen. In der Agentur wurde damit zu meinem Erleichtern gut umgegangen. Jegliche Fehler wurden sofort besprochen und konstruktiv geklärt.

Topmodernes Unternehmen mit Startup-flair

Neben den fachlichen Erkenntnissen entwickelte ich zudem ein hohes Maß an Selbstverantwortung. Durch das Projektmanagement-System war ich für alle meine Projekte und Deadlines selbst verantwortlich und musste meine Arbeitsweise vorausschauen und effektiv planen. Hinzu kam der tägliche Kundenkontakt. Auch hierbei wurde mir viel Vertrauen und Verantwortung geschenkt, sodass ich eigenständig mit Kunden kommunizieren durfte. Dabei versuchte ich immer einen höchst professionellen Eindruck zu machen, was laut Feedbackgespräch mit Bravour veräußert werden konnte. Zudem bin ich dankbar die Branchen Online Marketing und E-Commerce näher kennen gelernt zu haben. Meiner Meinung nach beinhalten diese sehr interessante Bereiche, in denen ich später durch Fachkenntnisse aus meinem Studiengang zu einem Fortschritt beitragen kann. Besonders was die Entwicklung von weiteren Tools und Softwarelösungen angeht, sehe ich riesiges Potenzial.

Das Praktikum ermöglichte mir einen Einblick in ein topmodernes Unternehmen mit Startup-flair, festigte mein Grundverständnis in diversen Bereichen der Informatik und inspirierte mich für neue Ideen in der Softwareentwicklung. Ein Pflichtpraktikum Webentwicklung bei den Online Rebellen lohnt sich also in jeder Hinsicht!

Hat euch der umfassende Einblick in unsere Agentur gefallen? Dann werdet ebenfalls Teil der Online Rebellion! Aktuelle Jobs findet ihr hier: https://www.online-rebellion.de//jobs/