Cocomore AG

Eingereicht von:

Projektname:

Lorenz Snack-World

Kategorie:

Architektur
Lorenz Snack-World screenshot desktop
Lorenz Snack-World screenshot Mobile
Lorenz Snack-World screenshot -Homepage
Lorenz Snack-World screenshot Homepage PL
Lorenz Snack-World screenshot Product page- desktop

Hintergrund

Lorenz Snack-World ist ein Multi-Site Drupal 8 Projekt, bei dem dieselbe Code Basis für mehrere Installationen genutzt wird, eine für jede Länderseite (Deutschland, Österreich, Polen und .com als allgemeine internationale Seite). Gleichzeitig haben alle Märkte (Länderseiten) ihre eigenen Konfigurationen und spezielle Features. Das Team startete bereits 2 Monate nach dem Release von Drupal 8.0.0 mit der Umsetzung. Leider fehlten zu diesem Zeitpunkt noch einige Contrib Module, oder sie waren in keiner stabilen Version vorhanden. Unter den gegebenen Bedingungen hatten wir einige technische Herausforderungen zu meistern, was uns dank unseres erfahrenen Drupal-Teams jedoch gelang.

 

Ziele

Die Lorenz Snack-World Seite, die zuvor auf Drupal 6 lief, sollte komplett neu gestaltet und auf Drupal 8 gerelaunched werden. Ein Hauptziel war es, die Seite visuell ansprechender zu gestalten (Design kam nicht von Cocomore) und die Verwaltung von Inhalten zu vereinfachen, so dass der Kunde diese möglichst einfach selbst editieren kann. Die Basis für alle 4 Länderseiten sollte weiterhin geteilt werden, aber die Inhalte wie z.B. Produkte unterschieden sich weiterhin von Land zu Land. Außerdem sollten auch nicht alle Funktionalitäten für alle Länder vorhanden sein. Des Weiteren war es wichtig, dass die Länderseiten alle zweisprachig (Landessprache und Englisch) angelegt und auch gepflegt werden können.

 

Ergebnisse 

Trotz der technischen Herausforderungen gelang es uns ein Produkt zu liefern, mit dem der Kunde glücklich ist. Die Inhaltsverwaltung gestaltet sich deutlich einfacher als im alten System, obwohl die einzelnen Unterseiten sehr unterschiedlich gestaltet sind und somit viele verschiedene Teasertypen zum Einsatz kommen. Dank der eingeführten Caching Strategie liefert die Seite auch wesentlich schneller aus als noch die alte Version, obwohl sie graphisch wesentlich aufwändiger umgesetzt wurde. 


Technische Herausforderungen

Viele Herausforderungen ergaben sich wie schon erwähnt durch das Fehlen bzw. den instabilen Status von Third-Party Modulen zu dem Zeitpunkt, zu dem wir das Projekt starteten. Die Challenges lassen sich wie folgt gruppieren:
** Multisite Konfiguration  **
Dank der neuen CMI Initiative, die in D8 eingeführt wurde, war es uns möglich einen Workflow zu entwickeln, bei dem Entwickler ihre Änderungen exportieren und dann erfolgreich in verschiedene Umgebungen deployen konnten. Allerdings hatten wir einige Sonderanforderungen zu berücksichtigen. Da Contrib Tools wie drush_cmi_tools oder Config split noch nicht bereit für D8 waren, konnten wir Konfigurationen noch nicht einzeln pro Seite handlen.
In diesem Zusammenhang definierten wir unterschiedliche config-Ordner, einen für jeden Markt. Wir entschieden uns dafür, die Konfiguration des Projekts in einem anderen Repository zu verwalten, so dass wir Änderungen zu einem oder mehreren config-Repositories deployen konnten. Außerdem war es uns so dank eines guten Branch-Handlings möglich, Features zu erweitern und unabhängig voneinander zu verwalten.
** Produkt Raster mit verschiedenen Konfigurationen pro Gerät **
•    Konfigurierbares Raster für die Produkte
•    Unterschiedliche Raster für unterschiedliche Geräte (mobil & Desktop): Hierzu nutzten wir die Mobile Detect Library https://github.com/serbanghita/Mobile-Detect
•    Hinzufügen von "Cache Context", so dass pro Gerät unterschiedlich gecached wird
Eine der Hauptfunktionalitäten der Website ist die Produktübersicht, die alle Produkte nach Brands gruppiert in einem attraktiven Format zugänglich machen soll. Um den Content-Editoren ausreichend Flexibilität zu bieten, um für jede Art von Geräten gut aussehende Strukturen erstellen zu können, waren verschiedene Layouts für mobile und Desktop-Version der Seite vorgesehen. Auf diese Weise kann eine Brand so gestaltet werden, dass in der Desktop-Version jedes Produkt dieser Brand mit einer eigenen Hintergrundfarbe und  zusammen mit unterschiedlichen Schmuckbildern angezeigt wird, während auf mobilen Endgeräten nur einige Produkte (auch mit einer eigenen Hintergrundfarbe) angezeigt werden, um lange Ladezeiten und endloses Scrollen des Benutzers zu vermeiden.
Wenn der Benutzer die Brand-Seite aufruft, erkennt das System, ob ein geeignetes Layout vorhanden ist. Dies geschieht, indem nach Entities gesucht wird, die der Brand zugeordnet sind  (Produkt plus die o.g. Zusatzinformationen), und außerdem mittels Einsatz der Mobile Detect Library, um das richtige Layout für das aufrufende Gerät auszuwählen.
Wenn wir das Standard Cache System benutzen würden, hätten wir so allerdings ein Problem gehabt, da die Seite immer so wie beim ersten Aufruf gecached werden würde und es keinen geeigneten Mechanismus gibt, um den Cache für verschiedene Geräte ungültig zu machen. Um dies zu vermeiden, verwendeten wir erneut die MobileDetect-Bibliothek, um einen benutzerdefinierten Cache Context zu erstellen.
** Definierte Cache Strategie **
•    Verwendung der Cache API mit Tags und Context, um die Performance zu erhöhen
•    Verwendung von Cache Tags und Context für die Eigenentwicklungen
Einer der Vorteile von Drupal 8 ist sein fortschrittliches und flexibles Cache System, das es uns erlaubt, attraktive Websiten zu gestalten, die ausgiebig Gebrauch von graphischen Gestaltungsmöglichkeiten zu machen, ohne die Ladezeiten für Enduser unnötig in die Höhe zu treiben. Aber angesichts der Tatsache, dass die Lorenz Snackworld Website so kurz nach dem Release von Drupal 8 entwickelt wurde, waren einige Contrib-Module nicht stabil genug und Costum-Module und Strukturen waren noch nicht definiert. Daher mussten wir mit der Cache-API und Tags und Contexts arbeiten, um sicherzustellen, dass dem Enduser immer der Inhalt in der neuesten und passenden Version angezeigt wird, der Cache aber gleichzeitig weitestgehend genutzt wird. Aus diesem Grund mussten wir nicht nur Tags und Contexts zu jedem einzelnen Inhalt hinzufügen, sondern wir mussten auch wie zuvor beschrieben einen eigenen Cache Context erstellen, und eigene Cache Tags nutzen, die dann entsprechend ungültig gemacht wurden, wenn erforderlich.
Ein Beispiel hierfür wäre der Warenkorb: Im Warenkorb kann ein eingeloggter Nutzer verschiedene Produkte sammeln, um Informationen über diese Produkte komprimiert in einer Zip-Datei herunterladen. Hierzu speichert das System Informationen in einem Cookie. Allerdings gibt es eine visuelle Hilfe beim Warenkorb, um die Anzahl der ausgewählten Produkte anzuzeigen. Wir verwenden einen benutzerdefinierten Cache Tag und stellen sicher, dass dieses jedes Mal, wenn der Benutzer ein neues Produkt zum Warenkorb hinzufügt, ungültig gemacht wird.


Drupal Community-Beitrag

Im Sinne von Code-Contribution haben wir nur einen kleinen Beitrag geleistet (https://www.drupal.org/node/2174633#comment-10385295). Wir haben aber auf dem DrupalCamp Spain  Granada 2016 und in lokalen UGs eine Session über "Display modes in Drupal 8" gehalten, um so unsere Erfahrungen, die wir während der Umsetzung des Projekts gesammelt haben, mit der Community zu teilen (http://slides.com/jlbellido/display-modes-drupal-8)

 

Erscheinungsdatum

01.04.2016