FirstSpirit Connect for Spryker Commerce OS

Ähnlich wie in FirstSpirit basieren Seiten in Spryker auf einer Struktur unterschiedlicher Komponenten. Um redaktionelle Inhalte zwischen den beiden Systemen austauschen zu können, müssen diese Komponenten aufeinander abgestimmt sein.

Innerhalb des in der Auslieferung enthaltenen Referenzprojekts FirstSpirit Connect Reference Project werden die CMS Slots aus Spryker durch die Inhaltsbereiche einer Seitenvorlage in FirstSpirit repräsentiert. Ihnen können Absätze hinzugefügt werden, die jeweils einem CMS Block entsprechen.

Mit FirstSpirit lassen sich somit CMS Blöcke generieren, die über CMS Slots in einer Seite dargestellt werden.

Die mit dem FirstSpirit Connect-Modul realisierte Integration sieht FirstSpirit-seitig lediglich die Erzeugung und Pflege der redaktionellen Inhalte sowie ihre Publizierung in Form von CMS Blöcken vor. Spryker bestimmt jedoch weiterhin das Rahmenwerk einer Seite, deren CMS Slots die generierten Blöcke einbinden.

Für die Darstellung der Vorschau einer Seite ermittelt FirstSpirit daher ihre aktuelle Ansicht in der Storefront. Diese fragt ihrerseits die redaktionellen Inhalte aus dem Preview CaaS ab und ersetzt die entsprechenden CMS Blöcke. FirstSpirit stellt das Resultat mithilfe des Omnichannel Managers im ContentCreator dar.

Die Übertragung der FirstSpirit-seitig erstellten Inhalte in den Live-Stand erfolgt durch Spryker. Dafür müssen die Inhalte bereitgestellt werden, was in Form des Online CaaS geschieht. Aus ihm importiert Spryker die redaktionellen Inhalte und persistiert sie in seinem Datensystem.

Die in FirstSpirit gepflegten Inhalte werden während eines Deployments mithilfe des Importers aus dem Online CaaS abgefragt. Der Importer überträgt die Daten nach Spryker und persistiert sie Backend-seitig in dessen Datensystem.

Da der Online CaaS potentiell eine große Datenmenge enthält, erfordert die Übertragung der Inhalte eine gewisse Zeitspanne. Frühzeitige Timeouts während des Imports sind daher zu vermeiden. Aus diesem Grund ist der Webserver der Glue-API so zu konfigurieren, dass er http-Requests für eine Dauer von mindestens 60 Sekunden erlaubt. Zusätzlich ist FirstSpirit-seitig der Socket-Timeout bei der Kommunikation mit der Glue-API entsprechend anzupassen (siehe Kapitel Konfiguration der Projekt-Komponente).

Die CaaS-Generierungen setzen voraus, dass im FirstSpirit-Projekt eine Vorlage für die Projekteinstellungen gepflegt ist. Andernfalls bricht der Generierungsauftrag frühzeitig ab und meldet den folgenden Fehler in den Auftragslogs:

Aus diesem Grund muss im Projekt eine entsprechende Vorlage existieren und diese in den Projektoptionen im ServerManager konfiguriert sein, selbst wenn sie keinen Inhalt besitzt.

Wie zuvor erwähnt ist die gesamte Dokumentation auf die Anbindung des Spryker B2C Demo Shops ausgerichtet. Bei dessen Verwendung können einige Schwierigkeiten auftreten, deren Ursache weder das FirstSpirit Connect-Modul noch die Integration ist. Dennoch werden sie nachfolgend aufgelistet und eine mögliche Lösung skizziert.

Vorschauseite wird im ContentCreator nicht gefunden

Kann der ContentCreator die Vorschauseite nicht finden, ist das Zertifikat der Seite ungültig oder nicht vorhanden. In diesem Fall muss die Seite in einem separaten Browser-Tab geöffnet werden, um das SSL-Zertifikat zu erneuern und die Anzeige der Seite zu erlauben. Anschließend ist die Vorschauseite im ContentCreator wieder sichtbar.

Fehlender RAM bei Composer-Aufrufen

Für PHP existiert standardmäßig ein RAM-Limit, das für die Ausführung von Composer-Aktionen jedoch zu niedrig ist. Aus diesem Grund muss das Limit, das in der Konfigurationsdatei php.ini im Verzeichnis etc/php/7.2/cli definiert ist, deaktiviert werden:

Die Pflege von Shop-Inhalten im ContentCreator erfordert die Installation mehrerer Spryker-Module, die in Form von zip-Dateien in der Auslieferung enthalten sind. Sie müssen in einem beliebigen Verzeichnis unterhalb des Spryker-Projektverzeichnisses gespeichert werden, das Composer als weiteres Repository bekannt zu machen ist. Dies geschieht über den im Projektverzeichnis auszuführenden Befehl, der die composer.json-Datei des Spryker-Servers entsprechend erweitert.

Die zu installierenden Spryker-Module nutzen den Namespace ESpirit, der Spryker bekannt zu machen ist. Dafür ist in der Environment-unabhängigen Datei config_default.php im Verzeichnis config/Shared eine Erweiterung der KernelConstants erforderlich:

Die Session Konstante für die Same Site Cookies muss nach der $config[KernelConstants::CORE_NAMESPACES] gesetzt sein:

Darüber hinaus muss die Domäne zur Whitelist-Konfiguration hinzugefügt werden:

Aktivieren Sie SSL in der yaml Datei deploy.dev.yml:

Die Installation der Spryker-Module erfolgt anschließend über die nachfolgenden Befehle, die ebenfalls im Spryker-Projektverzeichnis in der angegebenen Reihenfolge auszuführen sind.

Die Befehle laden die Module aus dem erstellten Repository und installieren sie automatisch.

Der letzte Schritt der Installation entspricht der Generierung der Transfer-Objekte des Data Import-Moduls sowie der Erzeugung des Datenbankschemas, das im CMS Block Data Connector-Modul enthalten ist:

Das FirstSpirit Connect-Modul stellt unterschiedliche Möglichkeiten bereit, auf Shop-Inhalte aus Spryker zuzugreifen und diese in FirstSpirit zu verwenden. Diese Möglichkeiten werden im weiteren Verlauf dieser Dokumentation anhand des mitgelieferten Referenzprojekts in Form von Anwendungsfällen beschrieben.

Besteht der Wunsch, die im Referenzprojekt enthaltenen Absatz- und Seitenvorlagen zu verwenden, setzt dies Spryker-seitig unterschiedliche Twig-Templates voraus.

Die Absätze entsprechen Spryker-seitig verschiedenen Molekülen, Atomen und Organismen, die im Ordner FirstSpiritReferenceComponents zusammengefasst sind. Dieser ist ein Bestandteil der Auslieferung und wird in Form eines weiteren Spryker-Moduls bereitgestellt, das über den folgenden Befehl zu installieren ist:

Damit die mit dem Modul zur Verfügung gestellten Komponenten Spryker-seitig einsetzbar sind, muss der ihnen zugehörige Pfad in Spryker bekannt gemacht werden. Dies erfolgt über die Anpassung der Dateien settings.js und tsconfig.json.

Innerhalb der settings.js-Datei im Verzeichnis Spryker-Verzeichnis/frontend ist eine Erweiterung des Kontextes notwendig:

Der tsconfig.json-Datei im Spryker-Verzeichnis ist ein weiterer Include hinzuzufügen:

Das generische Twig-Template fs_molecule_block.twig steuert die Ausgabe der mitgelieferten Moleküle. Es ist ein Bestandteil der in der Auslieferung enthaltenen zip-Datei b2c-demo-shop-extensions-<VERSION>.zip und muss Spryker-seitig unter dem Pfad src/Pyz/Shared/CmsBlock/Theme/default/template abgelegt werden.

Die Spryker-seitige Einbindung der Twig-Templates erfolgt über den nachfolgenden Befehl, der abschließend im Spryker-Projektverzeichnis auszuführen ist.

Die FirstSpirit-Vorlagen ermöglichen die Erweiterung bestehender statischer Seiten, Produkt- und Kategorieseiten sowie die Erzeugung dynamischer Inhaltsseiten oder eines Magazins. Das Referenzprojekt enthält dafür die Seitenvorlagen homepage, productpage, categorypage, contentpage und magazine_detail_page. Gleichzeitig müssen Spryker-seitig die folgenden Twig-Templates existieren:

Das Twig-Template home.twig, das unter dem Pfad src/Pyz/Yves/HomePage/Theme/default/views/home zu finden ist, benötigt einige Anpassungen. Diese sind in der Beschreibung statischer Seiten erläutert. Dasselbe gilt für die Twig-Templates pdp.twig, page-layout-catalog.twig und catalog-with-cms-slot.twig, die für die Bearbeitung von Produkt- und Kategorieseite erforderlich sind.

Sie sind in Spryker unter den folgenden Pfaden gespeichert:

Die übrigen Twig-Templates sind ein Bestandteil der in der Auslieferung enthaltenen zip-Datei und unter den folgenden Pfaden abzulegen:

Sowohl in Spryker als auch in FirstSpirit basieren Seiten auf einer Struktur unterschiedlicher Komponenten. Zu diesen zählen Spryker-seitig die CMS Slots, die in FirstSpirit durch die Inhaltsbereiche einer Seitenvorlage repräsentiert werden. Die Slots binden CMS Blöcke ein, die jeweils einem FirstSpirit-Absatz entsprechen.

Das Twig-Template home.twig stellt Spryker-seitig eine statische Seite dar und wird im mitgelieferten Referenzprojekt durch die Seitenvorlage homepage abgebildet. Diese besitzt die Inhaltsbereiche fs_slt_2 und fs_slt_3, für die in Spryker die zugehörigen Slots existieren müssen.

Der Import der Slots erfolgt mithilfe der Datei cms_slot.csv, die in Spryker im Verzeichnis /data/import/common/common gespeichert ist. Sie muss durch die gleichnamige Datei aus der Auslieferung ersetzt werden, die zusätzlich die folgenden beiden Zeilen enthält:

Die Übernahme der neuen Slots erfolgt anschließend über den nachfolgenden Befehl, der im Spryker-Projektverzeichnis auszuführen ist.

Die Erstellung und Bearbeitung redaktioneller Inhalte findet FirstSpirit-seitig im ContentCreator statt. In diesem ist mithilfe des Omnichannel Manager die Storefront eingebettet.

Um die Darstellung der Shop-Inhalte aus Spryker im ContentCreator zu ermöglichen, ist eine Erweiterung der umgebungsspezifischen Konfiguration erforderlich. Dafür muss in der Datei config_default-[environment].php im Verzeichnis config/Shared die Definition eines Tokens sowie die Angabe des Hosts und Ports der FirstSpirit-Startseite erfolgen. Außerdem erfordert der Betrieb des CaaS die Angabe einiger Parameter. Diese Parameter sind sowohl für den Produktivbetrieb als auch für den Einsatz des CaaS für die Vorschau notwendig.

Die config_default-[environment]_[storename].php Dateien können angepasst werden, um verschiedene Konfigurationen für verschiedene Stores zu erstellen:

Die Konfiguration FirstSpiritDataImportConstants::FIRSTSPIRIT_DATA_IMPORT_URL_TEMPLATE legt fest, wie die URLs für Inhaltsseiten aus FirstSpirit in Spryker generiert werden. Der Standard ist hierbei //, wobei locale die Sprache der Seite und url die von dem Editor in FirstSpirit hinterlegte URL abbildet. Zusätzlich kann die Variable store verwendet werden, welche das Kürzel für den verwendeten Store beinhaltet. Die Anpassungen an der URL-Struktur müssen im Ausgabekanal der Seitenvorlage für Inhaltsseiten wiedergespiegelt werden.

Damit die verwendete Klassen FirstSpiritPreviewConstants, FirstSpiritDataImportConstants und FirstSpiritCaaSConstants gefunden werden, sind sie per use-Statement in die Konfigurationsdatei einzubinden:

Der Omnichannel Manager ermöglicht die Darstellung und Bearbeitung externer Inhalte im ContentCreator, wofür er einige vorschauspezifische Data-Attribute benötigt. Darüber hinaus setzt er Spryker-seitig eine vorschauspezifische JavaScript-Datei voraus, die das FirstSpiritPreview-Modul einbindet.

Die JavaScript-Datei ist dem Twig-Template hinzuzufügen, das für das Basis-Layout aller Shopseiten verantwortlich ist. Im Standardfall handelt es sich dabei um das page-blank.twig-Template, das unter dem Pfad src/Pyz/Yves/ShopUi/Theme/default/templates/page-blank abgelegt ist. In demselben Template muss außerdem die Ermittlung der Data-Attribute durch die Twig-Funktion fsIncludeDataAttributes stattfinden.

Die Anpassung des Twig-Templates erfolgt über den Aufruf der Twig-Funktionen fsIncludeDataAttributes und fsIncludeOcmScript sowie über die Erweiterung der Template-Daten. Der Twig-Funktion fsIncludeOcmScript kann als optionaler Parameter die URL zu einer lokalen Kopie der JavaScript-Datei übergeben werden. Standardmäßig ermittelt sie die Datei aus dem CDN.

Anders als die mit FirstSpirit erstellten Inhalte, erfolgt die Übertragung der freigegebenen Medien nicht in den CaaS, sonden standardmäßig in ein von der Crownpeak Technology GmbH bereitgestelltes CDN. Der Auftrag enthält dafür die Skript-Aktion Execute Publish Media to CDN.

Das Skript ruft den Auftrag für die Mediengenerierung auf, der ebenfalls im bereitgestellten Referenzprojekt enthaltenen ist. Es enthält dafür die Variable SCHEDULER_NAME, die als Wert den Namen des Auftrags besitzt. Ändert sich der Name, ist er auch an dieser Stelle entsprechend anzupassen.

Standardmäßig speichert der CaaS die aus FirstSpirit übertragenden Inhalte seitenbasiert ab und liefert sie ebenso aus. Die Verarbeitung und Persistierung redaktioneller Inhalte erfolgt in Spryker jedoch auf der Grundlage von CMS Blöcken, die jeweils einem FirstSpirit-Absatz entprechen. Um diese Diskrepanz aufzulösen, müssen die im Online CaaS gespeicherten Daten daher vor dem Import entsprechend aufbereitet werden. Aus diesem Grund ist ausschließlich allen Collections des Online CaaS eine Aggregation hinzuzufügen. Für den Preview CaaS ist diese Anpassung nicht notwendig, da die Informationen im Vorschaufall direkt von ihm bezogen werden und keine Verarbeitung in Spryker stattfindet.

Der Auftrag enthält für die Erzeugung der Aggregationen die Skript-Aktion Setup CaaS Blocks Aggregations.

Das Skript führt für die konfigurierten Collections des Online CaaS einen PUT-Request aus. Dieser erzeugt die Aggregationen, mit deren Hilfe alle in den erweiterten Collections enthaltenen CMS Blöcke für Spryker zum Import bereitgestellt werden. Das Skript benötigt dafür die Liste der betreffenden Collections, die sich ihm mithilfe des optionalen Parameters caas_collections übergeben lässt.

Der Parameter besitzt standardmäßig den Wert contentpages;categorypages;productpages;technical und muss daher im Referenzprojekt nicht konfiguriert werden. Um den Default-Wert zu überschreiben, ist der Parameter caas_collections im Eigenschaftendialog des Skripts hinzuzufügen. Sein Wert muss einer per Semikolons separierten Liste aller Collections, für die eine Aggregation zu erzeugen ist, entsprechen.

Die Erstellung und Bearbeitung redaktioneller Inhalte findet FirstSpirit-seitig im ContentCreator statt. Sie werden nach der Freigabe per Deployment in den Online CaaS übertragen und aus diesem von Spryker importiert, um sie in den Shop zu integrieren. Um die Inhalte Spryker-seitig stets aktuell zu halten, muss der Importprozess durch das Deployment angestoßen werden. Der Auftrag enthält daher die Skript-Aktion Trigger Spryker Import. Das Skript aktiviert einen Spryker-seitigen Import-Job, der seinerseits den Import und die Persistierung der im Online CaaS gespeicherten Inhalte anstößt.

Die Spryker-seitige Löschung bzw. Deaktivierung von Kategorien oder Produkten, die im FirstSpirit-Projekt referenziert sind, führt zu Fehlern und Warnungen während des Imports. Diese werden standardmäßig jedoch nur im Spryker-Log erfasst. Um die Informationen zu einer Veröffentlichung gesammelt an einer Stelle bereitzustellen, müssen die Fehler und Warnungen auch im FirstSpirit-Log erfasst sein. Der Auftrag enthält daher die Skript-Aktion Trigger Fetch Spryker Logs. Sie ermittelt alle Fehler und Warnungen zu fehlenden Kategorien und Produkten aus dem Spryker-Log und überträgt sie jeweils als Warnung in das FirstSpirit-Log. Betriebsverantwortliche Personen erhalten damit die Möglichkeit, zeitnah auf die veralteten Referenzen im FirstSpirit-Projekt zu reagieren.

Die Erstellung und Bearbeitung redaktioneller Inhalte findet FirstSpirit-seitig statt, bevor sie per Deployment in den Online CaaS übertragen und aus diesem von Spryker importiert werden. Um den Datenbestand in beiden Systemen stets aktuell zu halten, sind aus dem FirstSpirit-Projekt gelöschte Inhalte auch Spryker-seitig zu entfernen. Der Auftrag enthält dafür die Skript-Aktion Trigger Spryker Cleanup. Das Skript stößt einen Abgleich zwischen den Inhalten an, die im Online CaaS gespeichert sowie im Datensystem Sprykers persistiert sind. Auf diesem Weg lassen sich Spryker-seitig die veralteten Daten ermitteln und anschließend entfernen.

Die Ausführung des Deployments der in FirstSpirit erstellten bzw. bearbeiteten Inhalte erfolgt in den meisten Fällen über den ContentCreator. Der ContentCreator informiert den Redakteur jedoch nicht darüber, ob eine Publikation erfolgreich war oder fehlgeschlagen ist. Aus diesem Grund enthält der Auftrag die Skript-Aktion Send Result Mail. Diese verschickt im Fehlerfall eine E-Mail mit allen relevanten Informationen an den Empfänger, der in den Eigenschaften des Auftrags im Feld eMail-Verteiler definiert ist. Die E-Mail enthält außerdem die Möglichkeit, diese Informationen an den Technical Support der Crownpeak Technology GmbH weiterzuleiten.

Für die Übertragung der Medien in das von der Crownpeak Technology GmbH bereitgestellte CDN müssen diese zunächst generiert werden. Der Auftrag enthält dafür die Generierungsaktion Media Generation. Sie entspricht einer Teilgenerierung, die sich auf den Root-Knoten der Medienverwaltung bezieht.

Um Inkonsistenzen im Live-Stand zu vermeiden, sind in den Eigenschaften der Aktion die Optionen Generierungsverzeichnis vorher leeren und Freigabestand generieren zu aktivieren. Des Weiteren ist es erforderlich, dass die an dieser Stelle für die Pfaderzeugung gewählte URL Factory und die URL-Factory für Mediennutzung, die in der Projekt-Komponente des CaaS konfiguriert ist, identisch sind.

Im Anschluss an die Generierung der Medien erfolgt ihre Übertragung in das CDN. Der Auftrag enthält dafür die Aktion Publish to CDN. Diese Aktion wird im Cloud-Umfeld durch die Cloud-Abteilung der Crownpeak Technology GmbH hinzugefügt und ist in diesem Fall bereits vorkonfiguriert. Eine weitere Konfiguration ist nicht erforderlich.

Das Referenzprojekt stellt die Möglichkeit zur Verfügung, eine bestehende Navigation zu erweitern oder eine komplett neue Navigation zu erzeugen. Ebenso wie bei Inhaltsänderungen ist eine Freigabe der Änderungen notwendig, um diese in den Live-Stand zu publizieren. Das Referenzprojekt enthält daher den Arbeitsablauf Freigabe der Navigation, für dessen Ausführung das Freigabe-Recht erforderlich ist. Der Arbeitsablauf führt lediglich die Freigabe einer globalen Seite für die Navigation durch und ist aus diesem Grund ausschließlich in den Globalen Einstellungen aktiviert. Er besitzt weder eine Konfliktbehandlung noch folgt er dem Vier-Augen-Prinzip.

Das Referenzprojekt enthält den Report Lost and Found, der eine Übersicht aller verwaisten Produkt- und Kategorieseiten anzeigt. Dabei handelt es sich um Seiten, die Referenzen auf Spryker-seitig gelöschte bzw. inaktive Produkte oder Kategorien beinhalten.

Jeder Eintrag des Reports besitzt einen Lösch-Button, der eine Entfernung der entsprechenden Seite ermöglicht. Das Referenzprojekt enthält dafür den Arbeitsablauf Direktes Löschen, der durch den Button angestoßen wird. Mit Ausnahme des Vier-Augen-Prinzips entspricht seine Funktionalität dem des im nachfolgenden Kapitel beschriebenen Lösch-BasicWorkflows. Zusätzlich zur Löschung der Seite, gibt der Arbeitsablauf die übergeordnete Struktur frei und führt abschließend ein Voll-Deployment durch.

Die Freigabe, die Löschung und die Publizierung von Inhalten durch Redakteure erfolgt innerhalb des bereitgestellten Referenzprojekts FirstSpirit Connect Reference Project über die BasicWorkflows. Diese wurden projektspezifisch angepasst und durch die Möglichkeit erweitert, eine Vollgenerierung auszuführen. Ebenso wie die Option der direkten Freigabe bzw. des direkten Löschens steht diese Möglichkeit jeweils nur den Rollen zur Verfügung, die das Freigabe- bzw. Löschen-Recht besitzen. Im Referenzprojekt handelt es sich dabei um die Gruppe ChiefEditors.

Beide Arbeitsabläufe verschicken darüber hinaus eine E-Mail an den Benutzer, der die Freigabe bzw. Löschung durchgeführt (und nicht nur angefordert) hat. Diese E-Mail teilt im Erfolgsfall lediglich die erfolgreiche Ausführung des Arbeitsablaufs mit. Im Fehlerfall weist sie darauf hin, dass der im Deployment-Auftrag angegebene Empfänger alle erforderlichen Informationen erhalten hat und zu kontaktieren ist.

Das nachfolgende Unterkapitel erläutert die vorgenommenen Anpassungen.

Installation des BasicWorkflows-Moduls

Vor der Verwendung der Arbeitsabläufe muss zunächst das BasicWorkflows-Modul auf dem FirstSpirit-Server installiert und die Web-Komponente aktiviert sein. Die dafür notwendigen Schritte sind analog zur Installation der anderen Module und der Aktivierung der zugehörigen Web-Komponenten. Standardmäßig sind diese Schritte bereits durchgeführt.

Der Einsatz der BasicWorkflows im ContentCreator erfordert darüber hinaus die Auswahl des bereitgestellten BasicWorkflows Status Providers im Bereich Projekt-Eigenschaften  ContentCreator innerhalb des ServerManagers. Im Referenzprojekt FirstSpirit Connect Reference Project ist diese Einstellung ebenfalls bereits vorgenommen.

Vorlagen

Die BasicWorkflows benötigen verschiedene Vorlagen. Diese müssen üblicherweise über das Kontextmenü in das verwendete FirstSpirit-Projekt importiert werden. Im Referenzprojekt sind sie jedoch bereits enthalten und ein Import der Vorlagen ist somit nicht notwendig.

Rechtevergabe

Im letzten Schritt müssen die Arbeitsabläufe in den einzelnen Verwaltungen erlaubt werden, um auf FirstSpirit-Elementen ausgeführt werden zu können. Dafür lässt sich auf den Root-Knoten der Verwaltungen über den Kontextmenüeintrag Extras  Rechte ändern die Rechtevergabe öffnen. Dieser Schritt ist im Referenzprojekt ebenfalls bereits durchgeführt und entfällt damit.

Die auf den Root-Knoten der Verwaltungen gesetzten Rechte zur Ausführung der Arbeitsabläufe beziehen sich auf die Gruppe Everyone. Falls dies nicht gewünscht ist, muss eine manuelle Anpassung der Rechte erfolgen.

Die BasicWorkflows besitzen standardmäßig zwei Möglichkeiten, ein Element freizugeben bzw. zu löschen:

In beiden Fällen steht die direkte Option jeweils nur den Rollen zur Verfügung, die das Freigabe- bzw. das Löschen-Recht besitzen. Im Referenzprojekt handelt es sich dabei um die Gruppe ChiefEditors. Andernfalls lässt sich eine Freigabe bzw. eine Löschung lediglich anfordern und einem nächsten Bearbeiter zuweisen. Dieser lehnt die Anforderung entweder ab, indem er manuell einen Konflikt auslöst, oder er stößt die Freigabe bzw. Löschung des Elements durch die Weiterschaltung des Arbeitsablaufs an.

Beide im Referenzprojekt bereitgestellten Arbeitsabläufe wurden projektspezifisch angepasst und durch die Möglichkeit erweitert, neben der Freigabe bzw. Löschung einer Seite eine Vollgenerierung auszuführen. Dafür wurde sowohl ihrem Start-Dialog als auch dem Dialog der Prüfung ein zusätzlicher Button hinzugefügt.

Im Freigabe-Arbeitsablauf handelt es sich dabei um den Button Publikation der Seite. Er entspricht der Transition trigger_release_and_deploy, die ebenso wie die direkte Freigabe nur mit dem Freigabe-Recht ausführbar ist.
Der Lösch-Arbeitsablauf hat den Button Löschen mit VP erhalten, der die Transition trigger_delete_and_deploy repräsentiert und sowohl das Freigabe- als auch das Löschen-Recht voraussetzt.

Beide Buttons führen das Skript set_value_for_deployment aus, das die Variable deploymentTriggered setzt. Diese wird im letzten Schritt des jeweiligen Arbeitsablaufs im Skript trigger_full_deployment ausgewertet und definiert, ob dieser lediglich eine Freigabe bzw. Löschung oder zusätzlich eine Vollgenerierung ausführt.

Um die Veröffentlichung anstoßen zu können, muss der durch das Skript trigger_full_deployment aufgerufenen Executable der Name der entsprechenden Vollgenerierung bekannt sein. Die Executable greift dafür auf die Combobox Veröffentlichungsauftrag zu, die im Reiter Veröffentlichung der Projekt-Komponente enthalten ist, und fragt den in ihr ausgewählten Auftrag ab. Innerhalb des Referenzprojekts ist an dieser Stelle die Vollgenerierung Spryker Deployment selektiert.

Beide Arbeitsabläufe verschicken außerdem nach ihrer Ausführung eine E-Mail an den Benutzer, der die Freigabe bzw. Löschung ausgeführt (und nicht nur angefordert) hat. Diese E-Mail teilt entweder lediglich die erfolgreiche Ausführung des Arbeitsablaufs mit oder macht auf einen während der Publikation aufgetretenen Fehler aufmerksam. In diesem Fall weist die E-Mail ebenfalls darauf hin, dass der im Deployment-Auftrag angegebene Empfänger alle benötigen Informationen erhalten hat und zu kontaktieren ist. Dies ist erforderlich, da nur Projektadministratoren Fehler im Deployment-Auftrag auflösen können.

Sowohl im Erfolgs- als auch im Fehlerfall greift die im letzen Schritt des jeweiligen Arbeitsablaufs aufgerufene Executable für den Versand der entsprechenden E-Mail auf die technische Seitenvorlage html_mail_template zu. Diese enthält die Texte aller E-Mails, die durch die Arbeitsabläufe oder Deployment-Aufträge verschickt werden.

Die Bearbeitung redaktioneller Inhalte erfolgt im FirstSpirit-Projekt grundsätzlich auf Basis einer Seitenreferenz. Sie und die ihr zugrundeliegende Seite müssen zunächst im FirstSpirit-Projekt angelegt werden. Innerhalb des Referenzprojekts FirstSpirit Connect Reference Project läuft die Erzeugung der Seitenreferenz und ihrer Seite automatisch im Hintergrund und für den Redakteur unsichtbar ab. Das Skript infer_page_storage_information ermittelt dabei anhand der im IndexController definierten Page Id die zugehörige FirstSpirit-Seitenvorlage.

Die im Referenzprojekt enthaltene Seitenvorlage homepage stellt ein Beispiel für eine statische Seite dar. Der folgende Code-Ausschnitt zeigt den Ausgabekanal dieser Seitenvorlage:

Die Seitenvorlage bildet das Twig-Template home.twig ab und besitzt die Inhaltsbereiche fs_slt_2 und fs_slt_3. Die Inhaltsbereiche ermöglichen die Ergänzung redaktioneller Inhalte, wofür im Referenzprojekt verschiedene Absatzvorlagen zur Verfügung stehen. Ihr Inhalt wird dem in der Vorlage erzeugten JSON-Objekt json hinzugefügt.

Zusätzlich zu den redaktionellen Inhalten werden dem JSON-Objekt die previewId, der identifier und der pagetype übergeben: Die previewId dient der Identifikation der Seitenreferenz und ermöglicht deren Dekoration im ContentCreator sowie ihr Mapping auf das Spryker-seitige Twig-Template. Die Identifikation der Seitenreferenz für die Vorschau erfolgt über das JavaScript des Omnichannel Managers. Die Spryker-seitige Erzeugung der Seite geschieht mithilfe des Identifiers. Er gewährleistet, dass die Seite in Spryker eindeutig ermittelbar ist. Außerdem muss bekannt sein, ob die zugrundeliegende Seite statisch oder dynamisch ist. Diese Information zeigt der Page Type an.

Das erzeugte JSON-Objekt ist ein Teil des zu generierenden CaaS-Items, dessen Spryker-seitige Persistierung durch den Importer erfolgt.

Die im Referenzprojekt enthaltene Seitenvorlage homepage stellt ein Beispiel für eine statische Seite dar. Sie enthält die Inhaltsbereiche fs_slt_2 und fs_slt_3. Diese ermöglichen die Ergänzung redaktioneller Inhalte. Dafür stehen unterschiedliche Absatzvorlagen zur Verfügung, die alle auf demselben Prinzip basieren. Eine von ihnen ist die Absatzvorlage shoppable_video, die an dieser Stelle exemplarisch beschrieben ist.

Innerhalb des Ausgabekanals des Shoppable Video-Absatzes erfolgt zunächst die Definition diverser allgemeiner Informationen und ihre Speicherung im Array block: Die previewId dient der Identifikation des Absatzes und ermöglicht dessen Bearbeitung im ContentCreator. Die Felder active und store_names geben an, dass der durch den Absatz repräsentierte CMS Block Spryker-seitig aktiv und in dem in den Projekteinstellungen ausgewählten Store sichtbar ist.

Die Ausgabe aller Absätze erfolgt Spryker-seitig durch das Twig-Template fs_molecule_block. Dieses entspricht einem generischen Template, das die Ausgabe aller Moleküle steuert. Um die Ausgabe eines Absatzes sowohl im Vorschaufall als auch im Live-Stand zu gewährleisten, müssen der Name und der Pfad dieses generischen Twig-Templates im CaaS-Item gespeichert sein. Beide Angaben sind daher in den allgemeinen Informationen des Absatzes enthalten.

Die Formatvorlage block_name_render ermittelt anschließend den Blocknamen. Dieser setzt sich aus dem Namen des übergeordneten Inhaltsbereichs sowie der ID des Absatzes zusammen.

Die Formatvorlage block_key_render verhält sich analog zur Formatvorlage block_name_render. Im Gegensatz zu dieser ermittelt sie jedoch nicht den Blocknamen, sondern den eindeutigen Key des entsprechenden Blocks.

Mithilfe der Formatvorlage additional_block_attributes_render werden dem Block weitere Attribute hinzugefügt. Bei diesen Attributen handelt es sich um den Slot-Key und die Position des Blocks innerhalb des Slots sowie um den Page Type und eine eindeutige ID.

Der Importer setzt das Feld placeholders im generierten CaaS-Item voraus. Daher ist es an dieser Stelle anzulegen, obwohl es keine Daten besitzt.

Das Array data beinhaltet die im Formular des Absatzes gepflegten redaktionellen Inhalte. Diese entsprechen der Video Id des ausgewählten YouTube-Videos und einer Liste von Video-Items, die auf der nachfolgend beschriebenen Absatzvorlage shoppable_video_item basieren. Sie werden zu definierten Zeitpunkten des Videos angezeigt. Für die Anzeige des Videos benötigt der Player die an dieser Stelle angegebene previewId. Der Absatz wird Spryker-seitig durch das Molekül fs-shoppable-video repräsentiert, dessen Name ebenfalls im data-Array enthalten ist.

Der Importer erwartet die Informationen im Kontext der aktuellen Sprache. Aus diesem Grund erfolgt eine Ermittlung des entsprechenden Sprachkürzels, dem das Array data zugeordnet wird.

Im Vorschaufall werden die Inhalte des Absatzes anschließend direkt ausgegeben. Andernfalls fügt der letzte Schritt den Absatz dem in der Seitenvorlage definierten Array blocks hinzu, das alle Absätze einer Seite enthält und sie in das zu generierende CaaS-Item integriert.

Wie zuvor erwähnt basieren die einzelnen Video-Items auf der Absatzvorlage shoppable_video_item. Innerhalb des Ausgabekanals dieser Vorlage erfolgt die Erfassung der redaktionellen Inhalte für ein einzelnes Video-Item und ihre Speicherung im Array item. Die redaktionellen Inhalte entsprechen dem Zeitpunkt, zu dem das Video-Item angezeigt wird, einem Bild, einem Text und einem Verweis auf die Detailseite eines auszuwählenden Produkts. Der letzte Schritt fügt das einzelne Video-Item dem in der Absatzvorlage shoppable_video definierten Array items hinzu, das alle Video-Items enthält und sie in das zu generierende CaaS-Item integriert.

Für die Eingabe des Anzeigezeitpunkts, des Bilds, des Textes sowie des Verweises eines Video-Items besitzt der Bearbeitungsdialog im ContentCreator den Button Open Video. Dieser öffnet einen weiteren Dialog, in dem das ausgewählte Video sichtbar und abspielbar ist. Mithilfe einer Zeitleiste lassen sich die Video-Items innerhalb dieses Dialogs intuitiv erstellen, bearbeiten oder löschen.

Die Erstellung und Bearbeitung redaktioneller Inhalte erfolgt FirstSpirit-seitig im ContentCreator. In diesem ist mithilfe des Omnichannel Managers die Storefront eingebettet. Diese greift ihrerseits auf den Preview CaaS zu und ermittelt aus diesem die aktuellen FirstSpirit-Inhalte. Per FirstSpirit-Deployment werden diese Inhalte in den Online CaaS übertragen. Dieser stellt sie dem Importer zur Verfügung, der sie nach Spryker überträgt und dort persistiert.

Das Twig-Template home.twig stellt Spryker-seitig eine statische Seite dar und ist unter dem Pfad src/Pyz/Yves/HomePage/Theme/default/views/home zu finden. Um diese Seite im ContentCreator bearbeitbar zu machen, ist eine Ersetzung der in ihr enthaltenen CMS Slots notwendig.

Die Einbindung eines Slots erfolgt über den Spryker-Standardbefehl cms_slot, der seinerseits das FirstSpiritPreviewSlotBlockWidgetCmsSlotContentPlugin aufruft. Dieses ist ein Bestandteil der Auslieferung und erfordert eine Erweiterung des ShopCmsSlotDependencyProviders. Es berücksichtigt im Gegensatz zu dem in Spryker enthaltenen CmsSlotBlockWidget ausschließlich die im CaaS gespeicherten Daten.

Das Twig-Template home.twig wird im Referenzprojekt durch die Seitenvorlage homepage abgebildet. Sie stellt ein Beispiel für eine statische Seite dar und besitzt die Inhaltsbereiche fs_slt_2 und fs_slt_3. Das folgende Code-Beispiel zeigt die Einbindung der gleichnamigen Slots innerhalb des Twig-Templates, um die statische Seite im ContentCreator bearbeitbar zu machen.

Die in der Seitenvorlage homepage enthaltenen Inhaltsbereiche fs_slt_2 und fs_slt_3 ermöglichen die Ergänzung redaktioneller Inhalte. Dafür stehen innerhalb des Referenzprojekts verschiedene Absatzvorlagen zur Verfügung, für die Spryker-seitig ein zugehöriges Block Twig-Template existieren muss. Eine dieser Vorlagen ist die Absatzvorlage shoppable_video, die Spryker-seitig durch das Molekül fs-shoppable-video repräsentiert wird. Dieses ist ein Bestandteil des in der Auslieferung enthaltenen Spryker- Moduls firstspirit-reference-components und Spryker-seitig im Verzeichnis FirstSpiritReferenceComponents abgelegt.

Der folgende Code-Ausschnitt zeigt den Inhalt des Moleküls fs-shoppable-video in stark gekürzter Form:

Innerhalb des Templates werden zunächst der Name und das Tag des Moleküls definiert. Anschließend erfolgt die Erzeugung des fsBlockData-Objekts. Es ermöglicht den Zugriff auf die strukturierten Daten, die im Ausgabekanal der FirstSpirit-Absatzvorlage definiert sind. Im Vorschaufall erfolgt der Bezug dieser Daten direkt aus dem Preview CaaS. Im Gegensatz dazu stammen die Daten für den Live-Stand aus Spryker. Dafür werden sie während der FirstSpirit-Generierung aus dem Online CaaS importiert und Spryker-seitig persistiert. Das fsBlockData-Objekt und das FirstSpirit-seitig erstellte JSON-Objekt besitzen somit in beiden Fällen dieselbe Struktur.

Der Block body beschreibt die Ausgabe der redaktionellen Inhalte. Diese entsprechen dem Zeitpunkt, zu dem das Video-Item angezeigt wird, einem Bild, einem Text und einem Verweis auf die Detailseite eines auszuwählenden Produkts.

Die folgende Abbildung zeigt die Darstellung des CMS Blocks.

Genauso wie die Bearbeitung statischer Seiten erfolgt auch die Erweiterung einer Kategorieseite im FirstSpirit-Projekt auf Basis einer Seitenreferenz. Sie und die ihr zugehörige Seite werden ebenfalls automatisch im Hintergrund und für den Redakteur unsichtbar angelegt.

Das Referenzprojekt enthält die Seitenvorlage categorypage, die ein Beispiel für eine Kategorieseite darstellt und das Twig-Template catalog-with-cms-slot.twig abbildet. Der folgende Code-Ausschnitt zeigt den Ausgabekanal dieser Seitenvorlage:

Der Ausgabekanal der Kategorieseite ist nahezu identisch mit dem der Homepage, die einer statischen Seite entspricht. Er unterscheidet sich lediglich in der Angabe des Page Type, der Revision Id sowie in der Anzahl der Inhaltsbereiche. Der Page Type dient der Ermittlung des Blocknamens und muss an dieser Stelle den Wert category besitzen. Die Ermittlung des Blocknamens in Abhängigkeit des Seitentyps erfolgt durch die Formatvorlage block_name_render, die im Ausgabekanal des jeweils eingebundenen Absatzes referenziert ist. Die Inhaltsbereiche der Seitenvorlage entsprechen den Spryker-seitig definierten CMS Block-Positionen. Sie müssen daher identisch benannt sein.

Zusätzlich zu dem bereits beschriebenen Shoppable Video-Absatz und dem Text-Bild-Absatz steht für die Ergänzung redaktioneller Inhalte auf Kategorieseiten die Absatzvorlage carousel_section zur Verfügung. Diese bindet wiederum ein oder mehrere Banner ein.

Das Banner ermöglicht die Auswahl eines zuschneidbaren Bilds sowie die Angabe eines Verweises, einer Überschrift und eines Untertitels. Sowohl für die Überschrift als auch für den Untertitel ist eine Textfarbe selektierbar. Im Gegensatz zu den anderen Absätzen, die sich lediglich auf Seiten für Unterkategorien verwenden lassen, ist die Einbindung des Banners auf allen Kategorieseiten möglich.

Das Banner entspricht dem Spryker-seitigen Molekül fs-banner.twig, dessen Ausgabe ebenfalls das generische Twig-Template fs_molecule_block.twig steuert. Dieses entspricht einem generischen Template, das die Ausgabe aller Moleküle reguliert.

Der Ausgabekanal des Banners ist nahezu identisch mit dem des Shoppable Video-Absatzes und unterscheidet sich lediglich in der Auswertung der zur Verfügung stehenden Eingabekomponenten. Aus diesem Grund sind keine zusätzlichen Erweiterungen erforderlich, die über die anhand des Shoppable Video-Absatzes bereits beschriebenen Anforderungen hinausgehen.

Die im Referenzprojekt enthaltene FirstSpirit-Seitenvorlage categorypage stellt ein Beispiel für eine Kategorieseite dar. Sie besitzt die Inhaltsbereiche banner, top und bottom und bildet das Twig-Template catalog-with-cms-slot.twig ab. Dieses ist Spryker-seitig unter dem Pfad src/Pyz/Yves/CatalogPage/Theme/default/views/catalog-with-cms-slot gespeichert und erweitert das übergeordnete Template page-layout-catalog.twig, in dem das Basis-Layout aller Kategorieseiten definiert ist.

Das folgende Code-Beispiel zeigt das Twig-Template catalog-with-cms-slot.twig inklusive der für die FirstSpirit-seitige Bearbeitung notwendigen Anpassungen. Da nur für die Positionen top und bottom Inhaltsbereiche in der FirstSpirit-Seitenvorlage existieren, erfolgt die Einbindung der CMS Blöcke ausschließlich in diesen beiden Fällen über die Twig-Funktion fsSpyCmsBlock.

Jeder CMS Block entspricht einem FirstSpirit-Absatz, der an einer bestimmten Position in einer Kategorieseite platziert ist. Die Verwendung von Positionen in Kategorieseiten ermöglicht Spryker-seitig das Feature CMS Block Category Connector, das innerhalb des Demo-Shops bereits konfiguriert ist. Das Feature stellt standardmäßig die Positionen top, middle und bottom bereit. Die Positionen werden FirstSpirit-seitig durch die Inhaltsbereiche der entsprechenden Seitenvorlage repräsentiert. Aus diesem Grund müssen die Namen der Inhaltsbereiche und die Namen der für Kategorieseiten definierten Positionen identisch sein.

Für die Einbindung des Banners muss das Feature zusätzlich um die Position banner erweitert werden. Dafür ist die Datei cms_block_category_position.csv innerhalb des Verzeichnisses data/import entsprechend anzupassen.

Damit die Positionen der Blöcke für Kategorieseiten bekannt sind, müssen die YAML-Dateien in data/import/local/ angepasst werden.

Die Übernahme der neuen Position erfolgt anschließend über den nachfolgenden Befehl, der im Spryker-Projektverzeichnis auszuführen ist.

Darüber hinaus ist der CMS Block banner dem übergeordneten Twig-Template page-layout-catalog.twig hinzuzufügen, das im Verzeichnis src/Pyz/Yves/CatalogPage/Theme/default/templates/page-layout-catalog abgelegt ist. Dafür muss der bereits bestehende Abschnitt block title innerhalb des Templates durch den folgenden Code ersetzt werden.

Das Banner entspricht Spryker-seitig dem Molekül fs-banner. Der folgende Code-Ausschnitt zeigt den Inhalt des Moleküls in stark gekürzter Form:

Innerhalb des Templates werden zunächst der Name und das Tag des Moleküls definiert. Anschließend erfolgt die Erzeugung des fsBlockData-Objekts. Es ermöglicht den Zugriff auf die strukturierten Daten, die im Ausgabekanal der FirstSpirit-Absatzvorlage definiert sind. Im Vorschaufall erfolgt der Bezug dieser Daten direkt aus dem Preview CaaS. Im Gegensatz dazu stammen die Daten für den Live-Stand aus Spryker. Dafür werden sie während der FirstSpirit-Generierung aus dem Online CaaS importiert und Spryker-seitig persistiert. Das fsBlockData-Objekt und das FirstSpirit-seitig erstellte JSON-Objekt besitzen somit in beiden Fällen dieselbe Struktur.

Der Block body beschreibt die Ausgabe der redaktionellen Inhalte. Diese entsprechen einem zuschneidbaren Bild und einem Verweis sowie einer Überschrift und einem Untertitel, für die jeweils eine Textfarbe definiert ist.

Die folgende Abbildung zeigt die Darstellung eines Karussells mit einem eingebundenen Banner im ContentCreator.

Die Ausgabe aller Moleküle steuert das generische Twig-Template fs_molecule_block.twig. Der folgende Code-Ausschnitt zeigt den Inhalt dieses Templates:

Wie im Twig-Template des Moleküls erfolgt in dem generischen Template zunächst die Erzeugung des fsBlockData-Objekts. Anschließend bindet der Block content das Molekül ein, das in der FirstSpirit-Absatzvorlage für den Parameter moleculename angegeben ist. Das Molekül ist Spryker-seitig im Verzeichnis FirstSpiritReferenceComponents abgelegt. Auf diesem Weg steuert das Twig-Template generisch die Ausgabe aller Moleküle und stellt das Mapping zwischen der FirstSpirit-Absatzvorlage und dem jeweiligen Spryker-seitigen Block Twig-Template her.

Das Attribut attributes ermöglicht die Bereitstellung zusätzlicher Konfigurationsattribute, die sich im Ausgabekanal einer Absatzvorlage definieren lassen. Sie werden auf diesem Weg direkt im Tag des zugehörigen Moleküls bereitgestellt, so dass auf sie mühelos per TypeScript zugegriffen werden kann. Sind innerhalb des Ausgabekanals eines Absatzes keine Konfigurationsattribute definiert, bleibt das Attribut attributes leer.

Die Bearbeitung einer Produktseite ist äquivalent zur Erweiterung einer Kategorieseite und erfolgt im FirstSpirit-Projekt ebenfalls auf Basis einer Seitenreferenz. Diese und die ihr zugehörige Seite werden automatisch im Hintergrund und für den Redakteur unsichtbar angelegt.

Die mit dem Referenzprojekt bereitgestellte Seitenvorlage productpage entspricht einer Produktseite. Sie bildet das Twig-Template pdp.twig ab und besitzt den im folgenden Code-Ausschnitt dargestellten Ausgabekanal.

Der Ausgabekanal der Produkt- und der Kategorieseite sind nahezu identisch. Sie unterscheiden sich lediglich in der Angabe der Page UID und der Product SKU sowie in der Anzahl der Inhaltsbereiche. Die Product SKU entspricht einer eindeutigen Produkt-ID, die zusammen mit der Page UID der eindeutigen Identifizierung der Produktseite in Spryker dient. Sie wird bei der Erstellung einer Produktseite im FirstSpirit-Projekt mithilfe des Skripts set_product_sku automatisch im Formular der Seite gespeichert.

Das Twig-Template product-cms-block.twig entspricht Spryker-seitig einem Produkt-Absatz und erweitert das übergeordnete Template pdp.twig, in dem das Basis-Layout aller Produktseiten definiert ist. Es ist ein Bestandteil der in der Auslieferung enthaltenen zip-Datei b2c-demo-shop-extensions-<VERSION>.zip und muss Spryker-seitig unter dem Pfad src/Pyz/Yves/CmsBlockWidget/Theme/default/components/molecules/product-cms-block abgelegt werden.

Das Template pdp.twig erfordert folgende Anpassung, um die Einbindung des Produkt-Absatzes zu ermöglichen.

Das folgende Code-Beispiel zeigt den Inhalt des Twig-Templates product-cms-block.twig. Es enthält zunächst den Namen des Moleküls und legt fest, dass die Angabe einer Product SKU erforderlich ist. Diese wird dem Twig-Template durch das übergeordnete Twig-Templates pdp.twig übergeben. Der Block body dient der Ausgabe der Inhalte, die für die entsprechende Produktseite gepflegt sind.

Ebenso wie die Bearbeitung statischer Seiten und Kategorieseiten erfolgt die Pflege dynamischer Inhaltsseiten im FirstSpirit-Projekt auf Basis einer Seitenreferenz. Dynamische Inhaltsseiten werden jedoch im Gegensatz zu den anderen Seiten, die bereits im Projekt bestehen, über den bekannten Redaktionsprozess neu erzeugt. Aus diesem Grund sind sie initial leer.

Die Erzeugung der Seitenreferenz im ContentCreator stößt ein Event des Omnichannel Managers an, das die Spryker-seitige Erstellung der zugehörigen CMS Page auslöst. Dies ist für die Anzeige der CMS Page in der Vorschau notwendig.

Das Referenzprojekt enthält die Seitenvorlage contentpage. Sie stellt ein Beispiel für dynamische Inhaltsseiten dar und bildet das Spryker-seitig anzulegende Twig-Template fs-content-page.twig ab.

Innerhalb des Ausgabekanals der Seitenvorlage erfolgt zunächst die Definition diverser allgemeiner Informationen und ihre Speicherung im JSON-Objekt des zu generierenden CaaS-Items: Die previewId dient der Identifikation der Seitenreferenz und ermöglicht deren Dekoration im ContentCreator sowie ihr Mapping auf das Spryker-seitige Twig-Template. Der automatisch ermittelte Name und der Pfad dieses Templates sind mithilfe der Felder template_name und template_path angegeben. Die Identifikation der Seitenreferenz für die Vorschau erfolgt über das JavaScript des Omnichannel Managers.

Ergänzend dazu dient der pagetype der Definition des Seitentyps. Im Fall dynamischer Inhaltsseiten muss das Feld den Wert cmspage besitzen.

Die Felder is_active und store_names geben an, dass das durch die Seite repräsentierte Twig-Template Spryker-seitig aktiv und in dem in den Projekteinstellungen ausgewählten Store sichtbar ist. Über das Feld is_searchable ist außerdem konfigurierbar, ob die Seite Spryker-seitig über ihren Namen suchbar ist. Im Gegensatz zur previewId, die nur für die Vorschau dient, ermöglicht der eindeutige identifier auch die Spryker-seitige Referenzierung des CaaS-Items.

Zusätzlich zu den allgemeinen Informationen werden dem JSON-Objekt mithilfe des Arrays localizedAttributes spezifische Informationen übergeben, die Spryker für jede Inhaltsseite voraussetzt. Sie dienen der Definition verschiedener Metadaten sowie der Angabe eines Seitennamens und der URL, unter der die Seite Spryker-seitig erreichbar sein wird. Während die verschiedenen Metadaten optional vom Redakteur im Formular der Seite eintragbar sind, handelt es sich bei der URL um ein sprachabhängiges Pflichtfeld. Sie muss die Struktur /Language Abbreviation/Subpath besitzen, wobei das Sprachkürzel der URL während der Generierung automatisch vorangestellt wird. Der Importer erwartet diese Informationen im Kontext der aktuellen Sprache. Aus diesem Grund erfolgt eine Ermittlung des entsprechenden Sprachkürzels, das jedem Attribut mit übergeben wird.

Die Seitenvorlage für dynamische Inhaltsseiten enthält die zwei Inhaltsbereiche content_top und content_body. Sie ermöglichen die Erzeugung redaktioneller Inhalte, wofür im Referenzprojekt verschiedene Absatzvorlagen zur Verfügung stehen. Ihre Inhalte werden nacheinander dem in der Vorlage erzeugten JSON-Objekt json hinzugefügt.

Im Gegensatz zu statischen Seiten und Kategorieseiten besitzen dynamische Inhaltsseiten sogenannte Placeholder. Diese entsprechen den Inhaltsbereichen der FirstSpirit-Seitenvorlage und enthalten Spryker-seitig lediglich Referenzen auf die ihnen zugeordneten CMS Blöcke. Im Anschluss an die Erfassung der redaktionellen Inhalte erfolgt daher für jeden Inhaltsbereich die Erzeugung dieser Referenzen.

Das Twig-Template fs-content-page.twig stellt Spryker-seitig eine dynamische Inhaltsseite dar. Diese besitzt im Gegensatz zu statischen Seiten und Kategorieseiten Placeholder. Um die Placeholder im ContentCreator bearbeitbar zu machen, ist für ihre Einbindung die Verwendung der Twig-Funktion fsSpyCms notwendig.

Jeder Placeholder repräsentiert einen Inhaltsbereich der entsprechenden FirstSpirit-Seitenvorlage. Aus diesem Grund müssen der Name des Placeholders und der Name des jeweiligen Inhaltsbereichs identisch sein. Jedem dieser Inhaltsbereiche lassen sich beliebig viele Absätze hinzufügen, für die Spryker-seitig ebenfalls ein Twig-Template existieren muss.

Die im Referenzprojekt enthaltene FirstSpirit-Seitenvorlage contentpage stellt ein Beispiel für dynamische Inhaltsseiten dar. Sie besitzt die Inhaltsbereiche content_top und content_body und bildet das Twig-Template fs-content-page.twig ab.

Innerhalb des Twig-Templates erfolgt zunächst die Definition spezifischer Metadaten sowie des Seitentitels. Anschließend erfolgt die Ausgabe der beiden Placeholder content_top und content_body in den Blöcken title und content. Sie referenzieren die ihnen zugeordneten CMS Blöcke, die ihrerseits die Ausgabe der redaktionellen Inhalte steuern.

Das folgende Code-Beispiel zeigt den Inhalt des Templates.

Sowohl die Magazinartikel als auch die Übersichtsseite basieren auf dynamischen Inhaltsseiten. Da sie sich in ihrer Struktur unterscheiden, benötigen die Magazinartikel im Gegensatz zur Übersichtsseite jedoch eine eigene Seitenvorlage. Diese entspricht im Referenzprojekt der Seitenvorlage magazine_detail_page und stellt eine Kopie der contentpage dar. Im Vergleich zur contentpage besitzt die magazine_detail_page jedoch nur einen Inhaltsbereich, der ausschließlich die Einbindung der Tabellenvorlage der Magazinartikel erlaubt.

Der folgende Code-Ausschnitt zeigt den Ausgabekanal der Seitenvorlage magazine_detail_page:

Der Ausgabekanal der Magazinartikel ist nahezu identisch mit dem dynamischer Inhaltsseiten. Er unterscheidet sich lediglich in den Angaben des Identifiers, einigen Attributen sowie der Anzahl der Inhaltsbereiche.

Der Identifier ermöglicht die Spryker-seitige Referenzierung des CaaS-Items und muss daher eindeutig sein. Würde er innerhalb des Ausgabekanals angegeben, besäßen jedoch alle Magazinartikel denselben Identifier. Aus diesem Grund ist er im Formular des entsprechenden Datensatzes gespeichert.

Anders als bei den dynamischen Inhaltsseiten erfolgt die Angabe der URL nicht im Formular der Seite, sondern ebenso wie der Identifier innerhalb des Datensatzes. Aus diesem Grund wird sie an dieser Stelle aus der Eingabekomponente des Datensatzes ermittelt. Für den Seitennamen wird die für den Magazinartikel definierte Überschrift herangezogen. Dies stellt sicher, dass jeder Magazinartikel einen eindeutigen Page Name besitzt.

Die umschließende If-Abfrage verhindert Generierungsfehler im Fall einer leeren Datenquelle.

Anders als bei den dynamischen Inhaltsseiten erfolgt die Ermittlung der redaktionellen Inhalte sowie die Erzeugung der Block-Referenzen für die Magazinartikel nicht innerhalb der Seitenvorlage, sondern im Ausgabekanal der zugehörigen Tabellenvorlage. Diese stellt den einzig zulässigen Inhalt für den Inhaltsbereich container dar.

Die Übersichtsseite entspricht einer dynamischen Inhaltsseite. Sie bindet die für sie notwendigen Daten mithilfe einer Absatzvorlage ein und erlaubt darüber hinaus die Ergänzung weiterer Absätze. Aus diesem Grund benötigt sie keine eigene Seitenvorlage.

Im Gegensatz zu den übrigen Seiten bilden die Magazinartikel einzelne Datensätze ab, die per Content Projection in einer Inhaltsseite eingebunden werden. Ihre Pflege und Bearbeitung erfolgt daher auf Basis einer Tabellenvorlage, die das entsprechende Formular bereitstellt und die Grundlage für die zugehörige Datenquelle bildet.

Die im Referenzprojekt enthaltene Tabellenvorlage magazine_articles gliedert sich thematisch in zwei Inhaltsblöcke:
Der erste Block bildet Spryker-seitig das Twig-Template fs-magazine-intro.twig ab und setzt sich aus übergeordneten Intro-Daten, wie beispielsweise einer Überschrift und verschiedenen Teaser-Informationen, zusammen. Für ihre Ermittlung wird innerhalb des Ausgabekanals der Tabellenvorlage die Formatvorlage magazine_intro_block_render_template referenziert, deren Ergebnis im Array contentTopBlocks gespeichert wird. Der Ausgabekanal dieser Formatvorlage ist nahezu identisch zum Ausgabekanal des Shoppable Video-Absatzes und unterscheidet sich lediglich in der Auswertung der zur Verfügung stehenden Eingabekomponenten.
Der zweite Block entspricht den einzelnen Absätzen der Magazinseite, die Spryker-seitig jeweils die ihnen zugehörigen Twig-Templates abbilden. Die Absätze sind in einem FS_CATALOG zusammengefasst, der im Ausgabekanal der Tabellenvorlage im Array contentBodyBlocks gespeichert wird.

Beide Arrays werden nacheinander dem in der Seitenvorlage erzeugten JSON-Objekt json hinzugefügt.

Da die Magazinartikel auf dynamischen Inhaltsseiten basieren, besitzen sie ebenfalls sogenannte Placeholder. Die Ausgabekanäle der Magazinartikel und der Inhaltsseiten sind daher ab diesem Punkt nahezu identisch. Sie unterscheiden sich lediglich in der Ausgabe des Placeholders für den Body-Bereich sowie in der Angabe der previewId. Im Gegensatz zu den Inhaltsseiten muss der Body-Bereich für die Magazinartikel auch in der Vorschau existieren, um die unerlaubte Ergänzung weiterer Absätze zu vermeiden. Die an dieser Stelle übergebene previewId überschreibt die Id der übergeordneten Seite, die alle Magazinartikel referenziert. Dies ist notwendig, da die previewId der Seite für alle Magazinartikel identisch ist, während die Ids der Artikel eindeutig sind.

Zusätzlich zu den einzelnen Magazinartikeln existiert eine Übersichtsseite, auf der die Artikel in Form von Teasern auf- oder absteigend nach einem Datum sortiert aufgelistet werden. Anders als bei den Magazinartikeln erfolgt die Ausgabe der redaktionellen Inhalte jedoch nicht über eine Content Projection, sondern über zwei ContentSelects. Das Referenzprojekt enthält daher die Absatzvorlage magazine_overview, die ausschließlich in dynamischen Inhaltsseiten verwendbar ist.

Der Ausgabekanal der Absatzvorlage enthält an erster Stelle die ContentSelects. Diese fragen alle Datensätze der Datenquelle magazine ab und speichern sie in unterschiedlicher Sortierung in den Variablen fr_st_teasers_descending bzw. fr_st_teasers_ascending.

Der nächste Schritt umfasst die Definition diverser Informationen, die auch in allen anderen Absätzen des Referenzprojekts enthalten sind. Der Ausgabekanal ist daher an dieser Stelle zu dem des Shoppable Video-Absatzes identisch.