ContentConnect

Ä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 ContentConnect Reference Project werden die CMS Placeholder 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.

Abbildung 2. Page Rendering

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

Die mit dem ContentConnect-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 Placeholder 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.

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:

Exception bei fehlender Einstellungsseite. 

error during script execution : java.lang.IllegalStateException:
Invalid value for key 'usedCaasProjects' - Value is not a HashMap (null).
This can happen when a deployment does not include a single PageRef (blue), which is not supported (e.g. remote-media-project).

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.

Abbildung 3. Konfiguration der Einstellungsseite in den Projektoptionen

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 ContentConnect-Modul noch die Integration ist. Dennoch werden sie nachfolgend aufgelistet und eine mögliche Lösung skizziert.

Vagrant findet VirtualBox nicht

Ist es Vagrant nicht möglich, VirtualBox zu finden, ist der vagrant up-Befehl wie folgt zu erweitern:

Erweiterung des Befehls vagrant up. 

vagrant up --provider=virtualbox

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:

Deaktivierung des RAM-Limits. 

[...]
set memory_limit=-1
[...]

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.

Erweiterung der composer.json-Datei. 

composer config repo.espirit artifact ./PATH-TO-DIRECTORY

Die zu installierenden Spryker-Module nutzen den Namespace FirstSpirit, 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:

Erweiterung der KernelConstants. 

$config[KernelConstants::CORE_NAMESPACES] = [
   'SprykerShop',
   'SprykerEco',
   'Spryker',
   'FirstSpirit'
];

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

Installationsbefehle. 

composer require firstspirit/firstspirit-caas
composer require firstspirit/firstspirit-preview
composer require firstspirit/firstspirit-data-state-writer
composer require firstspirit/firstspirit-data-cleanup
composer require firstspirit/firstspirit-data-import
composer require firstspirit/firstspirit-data-inconsistency-check
composer require firstspirit/firstspirit-data-rest-api
composer require firstspirit/firstspirit-cms-data-connector
composer require firstspirit/firstspirit-cms-data-storage

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:

Generierung der Transfer-Objekte und Erzeugung des Datenbankschemas. 

vendor/bin/console transfer:generate
vendor/bin/console propel:install

Das ContentConnect-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:

Installationsbefehl. 

composer require firstspirit/firstspirit-reference-components

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:

Anpassung der settings.js-Datei. 

[...]

dirs: [
   join(globalSettings.context, paths.core),
   join(globalSettings.context, './vendor/firstspirit'),
   join(globalSettings.context, paths.eco),
   join(globalSettings.context, paths.project)
],

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

Anpassung der tsconfig.json-Datei. 

[...]

"include": [
   "./vendor/spryker-shop/**/*",
   "./vendor/spryker-eco/**/*",
   "./src/Pyz/Yves/**/*",
   "./vendor/firstspirit/**/*"
],

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.

Einbindung der Twig-Templates. 

npm run yves

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 werden in der Beschreibung statischer Seiten erläutert. Die übrigen Twig-Templates sind ein Bestandteil der in der Auslieferung enthaltenen zip-Datei und unter den folgenden Pfaden abzulegen:

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.

Erweiterung der Konfiguration. 

// ----------- FirstSpirit Preview Configurations
$config[FirstSpiritPreviewConstants::FIRSTSPIRIT_PREVIEW_AUTHENTICATION_INIT_TOKEN] = '<ADD TOKEN>';
$config[FirstSpiritPreviewConstants::FIRSTSPIRIT_PREVIEW_WEB_HOST] = '<ADD FS PREVIEW HOST>';
$config[FirstSpiritPreviewConstants::FIRSTSPIRIT_PREVIEW_CAAS_CONTENT_PAGE_COLLECTION] = '<CAAS COLLECTION>';
$config[FirstSpiritPreviewConstants::FIRSTSPIRIT_PREVIEW_CAAS_CATEGORY_PAGE_COLLECTION] = '<CAAS COLLECTION>';
$config[FirstSpiritPreviewConstants::FIRSTSPIRIT_PREVIEW_CAAS_PRODUCT_PAGE_COLLECTION] = '<CAAS COLLECTION>';
$config[FirstSpiritPreviewConstants::FIRSTSPIRIT_PREVIEW_CAAS_TECHNICAL_PAGE_COLLECTION] = '<CAAS COLLECTION>';
$config[FirstSpiritPreviewConstants::FIRSTSPIRIT_PREVIEW_CAAS_NAVIGATION_DOCUMENT] = '<NAVIGATION DOCUMENT>';
$config[FirstSpiritPreviewConstants::FIRSTSPIRIT_PREVIEW_DISPLAY_BLOCK_RENDER_ERRORS] = true;

// ----------- FirstSpirit Data Import Configurations
$config[FirstSpiritDataImportConstants::FIRSTSPIRIT_DATA_IMPORT_BLOCK_DATA_CAAS_PATH] = '/_aggrs/blocks';
$config[FirstSpiritDataImportConstants::FIRSTSPIRIT_CAAS_REQUEST_PAGESIZE] = <VALUE>;

// ----------- FirstSpirit CaaS Configurations
$config[FirstSpiritCaaSConstants::FIRSTSPIRIT_CAAS_HOSTNAME_PREVIEW] = '<ADD CAAS HOST>';
$config[FirstSpiritCaaSConstants::FIRSTSPIRIT_CAAS_PORT_PREVIEW] = '<ADD CAAS PORT>';
$config[FirstSpiritCaaSConstants::FIRSTSPIRIT_CAAS_SCHEME_PREVIEW] = '<ADD CAAS SCHEME>';
$config[FirstSpiritCaaSConstants::FIRSTSPIRIT_CAAS_APIKEY_PREVIEW] = '<ADD APIKEY>';
$config[FirstSpiritCaaSConstants::FIRSTSPIRIT_CAAS_DATABASE_PREVIEW] = '<ADD CAAS DATABASE>';

$config[FirstSpiritCaaSConstants::FIRSTSPIRIT_CAAS_HOSTNAME_ONLINE] = '<ADD CAAS HOST>';
$config[FirstSpiritCaaSConstants::FIRSTSPIRIT_CAAS_PORT_ONLINE] = '<ADD CAAS PORT>';
$config[FirstSpiritCaaSConstants::FIRSTSPIRIT_CAAS_SCHEME_ONLINE] = '<ADD CAAS SCHEME>';
$config[FirstSpiritCaaSConstants::FIRSTSPIRIT_CAAS_APIKEY_ONLINE] = '<ADD APIKEY>';
$config[FirstSpiritCaaSConstants::FIRSTSPIRIT_CAAS_DATABASE_ONLINE] = '<ADD CAAS DATABASE>';

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

Einbindung der Klassen. 

use FirstSpirit\Shared\FirstSpiritPreview\FirstSpiritPreviewConstants;
use FirstSpirit\Shared\FirstSpiritDataImport\FirstSpiritDataImportConstants;
use FirstSpirit\Shared\FirstSpiritCaaS\FirstSpiritCaaSConstants;

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 einige vorschauspezifische JavaScript- und CSS-Dateien voraus, die im FirstSpiritPreview-Modul enthalten sind.

Sowohl die JavaScript- als auch die CSS-Dateien sind 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 fsIncludeOcmFiles sowie über die Erweiterung der Template-Daten. Die Twig-Funktion fsIncludeOcmFiles erwartet für die Einbindung der JavaScript- bzw. CSS-Dateien einen entsprechenden Identifier.

Anpassung des Twig-Templates. 

{% block headStyles %}
   <link rel="stylesheet" href="{{publicPath('css/yves_default.app.css')}}" />
   {{ fsIncludeOcmFiles(identifier='css') }}
{% endblock %}

<body [..] {{ fsIncludeDataAttributes() }}>

   [..]

   {% block footerScripts %}
      <script src="{{publicPath('js/yves_default.es6-polyfill.js')}}"></script>
      <script src="{{publicPath('js/yves_default.vendor.js')}}"></script>
      <script src="{{publicPath('js/yves_default.app.js')}}"></script>
      {{ fsIncludeOcmFiles(identifier='js') }}
   {% endblock %}

</body>

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

Execute Publish Media to CDN. 

import de.espirit.firstspirit.access.AdminService;

String SCHEDULER_NAME = "Media Deployment";

connection = context.getConnection();
adminService = connection.getService(AdminService.class);

scheduleStorage = adminService.getScheduleStorage();
scheduleEntry = scheduleStorage.getScheduleEntry(context.getProject(), SCHEDULER_NAME);

if(scheduleEntry != null) {
   control = scheduleEntry.execute();
   control.awaitTermination();
   isSuccessful =
      control.state.state.equals(de.espirit.firstspirit.access.schedule.RunState.SUCCESS);
   if(!isSuccessful){
      context.logWarning(SCHEDULER_NAME + " Completed with errors!");
   }
   context.logInfo("Schedule Entry executed...");
} else {
   context.logError("Could not find schedule entry with name" + SCHEDULER_NAME);
}

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.

Setup CaaS Blocks Aggregations. 

#! executable-class
com.espirit.ecom.contentconnect.spryker.module.caas.BlocksAggregationSetupExecutable

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.

Abbildung 15. Konfigurationsparameter

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.

Trigger Spryker Import. 

#!executable-class
com.espirit.ecom.contentconnect.spryker.module.trigger.triggerimport.TriggerImportExecutable

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.

Trigger Fetch Spryker Logs. 

#!executable-class
com.espirit.ecom.contentconnect.spryker.module.trigger.triggerfetchlogs.TriggerFetchLogsExecutable

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.

Trigger Spryker Cleanup. 

#!executable-class
com.espirit.ecom.contentconnect.spryker.module.trigger.triggercleanup.TriggerCleanupExecutable

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 e-Spirit AG weiterzuleiten.

Trigger Spryker Cleanup. 

#! executable-class
com.espirit.ecom.contentconnect.spryker.module.schedule.ReviewScheduleResultExecutable

Für die Übertragung der Medien in das von der e-Spirit AG 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.

Abbildung 17. Eigenschaften der Aktion Media Generation

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 e-Spirit AG hinzugefügt und ist in diesem Fall bereits vorkonfiguriert. Eine weitere Konfiguration ist nicht erforderlich.

Abbildung 18. Publish to CDN

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 ContentConnect 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 ContentConnect Reference Project ist diese Einstellung ebenfalls bereits vorgenommen.

Abbildung 21. Element Status Provider

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.

Abbildung 22. Erweiterung des Freigabe-Arbeitsablaufs

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 ContentConnect 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:

Ausgabekanal der Seitenvorlage homepage. 

$CMS_TRIM(level:1)$
   $CMS_SET(json, {:})$
   $CMS_SET(previewId, previewId(element:#global.node))$
   $CMS_SET(void, json.put("previewId", "" + previewId))$
   $CMS_SET(void, json.put("pagetype", "static"))$
   $CMS_SET(void, json.put("identifier", #global.node.uid))$

   $CMS_SET(blocks, [])$
   $CMS_VALUE(#global.page.body("stage"))$
   $CMS_VALUE(#global.page.body("homepage_one"))$
   $CMS_VALUE(#global.page.body("homepage_two"))$
   $CMS_VALUE(#global.page.body("homepage_three"))$
   $CMS_VALUE(#global.page.body("homepage_four"))$

   $CMS_SET(void, json.put("blocks", blocks))$

   $CMS_VALUE(json.toJSON)$
$CMS_END_TRIM$

Die Seite bildet das Twig-Template home.twig ab und besitzt die Inhaltsbereiche stage sowie homepage_one|two|three|four. 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 Page Type ü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 stage sowie homepage_one|two|three|four. Der Inhaltsbereich stage stellt lediglich ein Karussell bereit, das ein oder mehrere Banner einbindet. Im Gegensatz dazu ermöglichen die übrigen Inhaltsbereiche 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 wird.

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 des Absatzes 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 des Absatzes sowohl im Vorschaufall als auch im Live-Stand zu gewährleisten, müssen der Name und der Pfad dieses Twig-Templates im CaaS-Item gespeichert sein.

Definition allgemeiner Informationen im Ausgabekanal des Absatzes. 

$CMS_SET(block,{:})$

$-- Defining general block data --$
$CMS_SET(void, block.put("previewId", "" + previewId()))$
$CMS_SET(void, block.put("active", "1"))$
$CMS_SET(void, block.put("store_names", [ps_activeStore]))$
$CMS_SET(void, block.put("template_name", "fs_molecule_block"))$
$CMS_SET(void, block.put("template_path", "@CmsBlock/template/fs_molecule_block.twig"))$

Die Formatvorlage block_name_render ermittelt anschließend den Blocknamen. Generell sind die Inhaltsbereiche einer Seitenvorlage äquivalent zu den CMS Placeholdern in Spryker. Eine statische Seite enthält jedoch keine Placeholder. Aus diesem Grund muss der Blockname an dieser Stelle dem Namen des zugehörigen Inhaltsbereichs entsprechen.

Mithilfe der Formatvorlage additional_block_attributes_render werden dem Block bei Bedarf weitere Attribute hinzugefügt.

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

Ermittlung spezifischer Informationen im Ausgabekanal des Absatzes. 

$CMS_SET(set_pageType, json.get("pagetype"))$

$-- Add block name attribute to block object (page type dependent) --$
$CMS_RENDER(template: "block_name_render", rt_pageType: set_pageType, rt_blockObject: block)$

$-- Add additional block attributes to block object (page type dependent) --$
$CMS_RENDER(template: "additional_block_attributes_render", rt_pageType: set_pageType, rt_blockObject: block)$

$-- Defining placeholder data of the block --$
$CMS_SET(placeholders,{:})$
$CMS_SET(void, block.put("placeholder",placeholders))$

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.

Verarbeitung der redaktionellen Inhalte im Ausgabekanal des Absatzes. 

$CMS_SET(data,{:})$
$CMS_SET(void, data.put("moleculename", "fs-shoppable-video"))$
$CMS_SET(void, data.put("videoId", if(!st_video.empty,st_video.values.first.id)))$
$CMS_SET(void, data.put("previewId", previewId()))$

$CMS_SET(items,[])$
$CMS_VALUE(st_items)$
$CMS_SET(void, data.put("items", items))$

$CMS_SET(locale, #global.language.getLocale())$
$CMS_SET(localeAbbr, locale.getLanguage() + "_" + locale.getCountry())$
$CMS_SET(localizedData,{:})$
$CMS_SET(void, localizedData.put(localeAbbr, data))$
$CMS_SET(void, block.put("data", localizedData))$

$CMS_IF(#global.is("WEBEDIT") && !isSet(caas_preview_generation))$
   $CMS_VALUE(block.toJSON)$
$CMS_ELSE$
   $CMS_SET(void, blocks.add(block))$
$CMS_END_IF$

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.

Ausgabekanal des Video-Items. 

$CMS_SET(item, {"time": st_time})$

$CMS_IF(!st_picture.empty)$
   $CMS_SET(void, item.put("picture", {
      "imageUrl": ref(st_picture, res:"CONTENT_IMAGE", abs:1).url,
      "ambilight": !st_ambilight.empty && st_ambilight
   }))$
   $CMS_IF(!#global.release)$
      $CMS_SET(void, item.picture.put("previewId", previewId(element: st_picture)))$
   $CMS_END_IF$
$CMS_END_IF$

$CMS_IF(!st_text.empty)$
   $CMS_SET(void, item.put("text", st_text.normalize.toText(true)))$
$CMS_END_IF$

$CMS_IF(!st_product.empty)$
   $CMS_SET(void, item.put("productId", st_product.identifiers.get(0)))$
$CMS_END_IF$

$CMS_SET(void, items.add(item))$

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.

Abbildung 25. Bearbeitungsdialog für Video-Items

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, müssen die bestehenden CMS Blöcke ersetzt werden. Für die Einbindung eines Blocks ist die Verwendung der Twig-Funktion fsSpyCmsBlock notwendig.

Im Fall statischer Seiten repräsentiert jeder Block einen Inhaltsbereich der entsprechenden FirstSpirit-Seitenvorlage. Aus diesem Grund müssen der Name des CMS Blocks und der Name des jeweiligen Inhaltsbereichs identisch sein. Jedem dieser Inhaltsbereiche kann nur genau ein Absatz hinzugefügt werden, für den Spryker-seitig ein Block Twig-Template existieren muss.

Die im Referenzprojekt enthaltene Seitenvorlage homepage stellt ein Beispiel für eine statische Seite dar. Sie bildet das Twig-Template home.twig ab und besitzt die Inhaltsbereiche stage sowie homepage_oneone|two|three|four. Das folgende Code-Beispiel zeigt die Einbindung der gleichnamigen Blocks innerhalb des Twig-Templates, um die statische Seite im ContentCreator bearbeitbar zu machen.

Erweiterung des Twig-Templates home.twig. 

{% extends template('page-layout-main') %}

{% block header %}
   [...]
{% endblock %}

{% block pageInfo %}{% endblock %}

{% block container %}
   {{ fsSpyCmsBlock({ name: 'stage' }) }}
   <div class="container container--home-page">
      <main>
         {% block content %}
            {{ fsSpyCmsBlock({ name: 'homepage_one' }) }}
            {{ fsSpyCmsBlock({ name: 'homepage_two' }) }}
            {{ fsSpyCmsBlock({ name: 'homepage_three' }) }}
            {{ fsSpyCmsBlock({ name: 'homepage_four' }) }}

         {% endblock %}
      </main>
   </div>
{% endblock %}

Der in der Seitenvorlage homepage enthaltene Inhaltsbereich stage stellt lediglich ein Karussell bereit, das ein oder mehrere Banner einbindet. Im Gegensatz dazu ermöglichen die übrigen Inhaltsbereiche 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:

Molekül fs-shoppable-video. 

{% extends model('component') %}

{% define config = {
   name: 'fs-shoppable-video',
   tag: 'fs-shoppable-video'
} %}

{% define data = {
   fsBlockData: [],
} %}

{% block body %}
   [...]
   <fs-youtube-player video-id="{{ data.fsBlockData.videoId }}" nocookie muted>
      {% for item in data.fsBlockData.items %}
         <div data-time="{{ item.time }}">
            {% set url = item.productId is defined ? getProductPageUrl(item.productId):null %}
            <a href="{{url}}">
               {% set ambilight = item.picture.ambilight is defined and item.picture.ambilight %}
               <span class="picture{{ambilight ? 'with-ambilight':''}}"
                  style="background-image: url('{{ item.picture.imageUrl }}');">
               </span>
               [...]
               {{ item.text | raw }}
               [...]
            </a>
            [...]
         </div>
      {% endfor %}
   </fs-youtube-player>
   <script type="module" src="https://www.unpkg.com/fs-youtube-player"></script>
{% endblock %}

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.

Abbildung 26. Darstellung des Absatzes

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

generisches Twig-Template für die Ausgabe aller Moleküle. 

{% define data = {
   fsBlockData: fsBlockData()
} %}

{% block content %}
   {% include molecule( data.fsBlockData.moleculename, 'FirstSpiritReferenceComponents') with{
      data: {
         fsBlockData: data.fsBlockData
      }
      attributes: {
         'data-attributes': data.fsBlockData.attributes | default('') | json_encode
      }
   }only %}
{% endblock %}

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-seitige 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.

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 page-layout-catalog.twig abbildet. Der folgende Code-Ausschnitt zeigt den Ausgabekanal dieser Seitenvorlage:

Ausgabekanal der Seitenvorlage categorypage. 

$CMS_TRIM(level:1)$
   $CMS_SET(json, {:})$
   $CMS_SET(previewId, previewId(element:#global.node))$
   $CMS_SET(void, json.put("previewId", "" + previewId))$
   $CMS_SET(void, json.put("pageRevisionId", #global.page.revision.id))$
   $CMS_SET(void, json.put("pagetype", "category"))$
   $CMS_SET(blocks, [])$

   $CMS_VALUE(#global.page.body("banner"))$
   $CMS_VALUE(#global.page.body("top"))$
   $CMS_VALUE(#global.page.body("bottom"))$
   $CMS_SET(void, json.put("blocks", blocks))$

   $CMS_VALUE(json.toJSON)$
$CMS_END_TRIM$

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, die beide nur auf Seiten für Unterkategorien verwendbar sind, steht auf allen 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 einer Überschrift und eines Untertitels. Sowohl für die Überschrift als auch für den Untertitel ist eine Textfarbe selektierbar. Das Banner entspricht dem Spryker-seitigen Molekül fs-banner.twig, dessen Ausgabe ebenfalls das generische Twig-Template fs_molecule_block.twig steuert.

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.

Das Twig-Template catalog-with-cms-block.twig stellt Spryker-seitig einen Kategorie-Absatz dar. Es erweitert das übergeordnete Template page-layout-catalog.twig, in dem das Basis-Layout aller Kategorieseiten definiert ist.

Um Kategorieseiten im ContentCreator bearbeitbar zu machen, muss die Einbindung der CMS Blöcke innerhalb dieser Templates über die Twig-Funktion fsSpyCmsBlock erfolgen.

Jeder CMS Block entspricht einem FirstSpirit-Absatz, der an einer bestimmten Position in der Kategorieseite platziert ist. Die Verwendung von Positionen in Kategorieseiten wird Spryker-seitig durch das Feature CMS Block Category Connector ermöglicht, 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. Die Übernahme der neuen Position erfolgt anschließend über den nachfolgenden Befehl, der im Spryker-Projektverzeichnis auszuführen ist.

Aktualisierungsbefehl. 

console data:import:cms-block-category-position

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 page-layout-catalog.twig ab. Dieses wird durch das Twig-Template catalog-with-cms-block.twig erweitert, das ein Bestandteil der in der Auslieferung enthaltenen zip-Datei b2c-demo-shop-extensions-<VERSION>.zip ist. Das Twig-Template catalog-with-cms-block.twig ermöglicht die Einbindung der in den Inhaltsbereichen top und bottom enthaltenen Absätze auf Seiten für Unterkategorien.

Während die CMS Blöcke top und bottom spezifisch für diese Unterkategorieseiten sind, steht der CMS Block banner auf allen Kategorieseiten zur Verfügung. Aus diesem Grund ist er 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. Für die Ergänzung des Banners muss der bereits bestehende Abschnitt block title innerhalb des Templates durch den folgenden Code ersetzt werden.

Einbindung des Banners. 

{% block title %}
   {{ fsSpyCmsBlock({category:data.category.id_category, position: 'banner'}) }}
{% endblock %}

Das Banner entspricht Spryker-seitig dem Molekül fs-banner, dessen Ausgabe das generische Twig-Template fs_molecule_block.twig steuert. Der folgende Code-Ausschnitt zeigt den Inhalt des Moleküls:

Molekül fs-banner. 

{% extends model('component') %}

{% define config = {
   name: 'fs-banner',
   tag: 'fs-banner'
} %}

{% define data = {
   fsBlockData: []
} %}

{% block body %}
   <figure class="fs-banner"{% if data.fsBlockData.variant is not empty %} data-variant="{{data.fsBlockData.variant}}"{% endif %}>
      <img src="{{ data.fsBlockData.picture.imageUrl }}"
         {% if data.fsBlockData.picture.previewId is defined %}
            data-preview-id="{{ data.fsBlockData.picture.previewId }}"
            data-tpp-context-image-resolution="BANNER_IMAGE"
         {% endif %}>

      {% if (data.fsBlockData.title is not empty) or (data.fsBlockData.subtitle is not empty) %}
         <figcaption>
            <hgroup>
               {% if data.fsBlockData.title is not empty %}
                  <h2>{{ data.fsBlockData.title | raw}}</h2>
               {% endif %}
               {% if data.fsBlockData.subtitle is not empty %}
                  <h3>{{ data.fsBlockData.subtitle | raw}}</h3>
               {% endif %}
            </hgroup>
         </figcaption>
      {% endif %}
   </figure>
{% endblock %}

Ebenso wie beim Molekül des Shoppable Video-Absatzes wird innerhalb des Templates zunächst der Name des Moleküls definiert und anschließend das fsBlockData-Objekt erzeugt. Es ermöglicht den Zugriff auf die strukturierten Daten, die im Ausgabekanal der FirstSpirit-Absatzvorlage definiert sind. Das fsBlockData-Objekt und das FirstSpirit-seitig erstellte JSON-Objekt besitzen somit dieselbe Struktur.

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

Die folgende Abbildung zeigt die Darstellung eines Karussells mit nur einem Element im ContentCreator.

Abbildung 27. Karussell mit einem Element

Das folgende Code-Beispiel entspricht dem Twig-Template catalog-with-cms-block.twig inklusive der für die FirstSpirit-seitige Bearbeitung notwendigen Anpassungen. Es ermöglicht die Einbindung der übrigen Absätze, die nicht dem Karussell entsprechen, auf Seiten für Unterkategorien. 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.

Anpassung des Twig-Templates catalog-with-cms-block.twig. 

{% extends template('widget') %}

{% block top %}
   {{ fsSpyCmsBlock({category: _widget.idCategory, position: 'top'}) }}
{% endblock %}

{% block middle %}
   {{ spyCmsBlock({category: _widget.idCategory, position: 'middle'}) }}
{% endblock %}

{% block bottom %}
   {{ fsSpyCmsBlock({category: _widget.idCategory, position: 'bottom'}) }}
{% endblock %}

{% block body %}
   {{ spyCmsBlock({category: _widget.idCategory, position: _widget.position}) }}
{% endblock %}

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.

Ausgabekanal der Seitenvorlage productpage. 

$CMS_TRIM(level:1)$
   $CMS_SET(json, {:})$
   $CMS_SET(previewId, previewId(element:#global.node))$
	$CMS_SET(void, json.put("previewId", "" + previewId))$
	$CMS_SET(void, json.put("pageRevisionId", #global.page.revision.id))$
	$CMS_SET(void, json.put("pagetype", "product"))$
	$-- Page uid is needed for later identification when setting the SKU of the page --$
	$CMS_SET(void, json.put("page_uid", #global.page.uid))$
	$CMS_SET(void, json.put("product_sku", pt_productSku))$
	$CMS_SET(blocks, [])$

	$CMS_VALUE(#global.page.body("content"))$
	$CMS_SET(void, json.put("blocks", blocks))$

	$CMS_VALUE(json.toJSON)$
$CMS_END_TRIM$

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. Es erweitert das übergeordnete Template pdp.twig, in dem das Basis-Layout aller Produktseiten definiert ist.

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.

Twig-Template product-cms-block.twig. 

{% extends model('component') %}

{% define config = {
   name: 'product-cms-block'
} %}

{% define data = {
   idProductAbstract: required
} %}

{% block body %}
   {{ fsSpyCmsBlock({ product: data.idProductAbstract }) }}
{% endblock %}

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.

Definition allgemeiner Informationen im Ausgabekanal der Seitenvorlage. 

$CMS_SET(json, {:})$
$CMS_SET(previewId, previewId(element:#global.node))$
$CMS_SET(void, json.put("previewId", "" + previewId))$
$CMS_SET(void, json.put("template_name", pt_cmsPageTemplateName))$
$CMS_SET(void, json.put("template_path", "@Cms/templates/fs-content-page/fs-content-page.twig"))$
$CMS_SET(void, json.put("pagetype", "cmspage"))$
$CMS_SET(void, json.put("is_active", "1"))$
$CMS_SET(void, json.put("store_names", [ps_activeStore]))$
$CMS_SET(void, json.put("is_searchable", "1"))$
$CMS_SET(void, json.put("identifier", #global.node.uid))$

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.

Definition spezifischer Informationen. 

$CMS_SET(locale, #global.language.getLocale())$
$CMS_SET(localeAbbr, locale.getLanguage() + "_" + locale.getCountry())$

$CMS_SET(attributes, {:})$
$CMS_IF(pt_url != null && !pt_url.isEmpty())$
   $CMS_SET(url, "/" + locale.getLanguage() + if(!pt_url.startsWith("/"), "/") + pt_url.convert2)$
   $CMS_SET(void, attributes.put("url", {localeAbbr: url}))$
$CMS_ELSE$
   $CMS_SET(void,#global.logError(
      "Missing url for contentpage " + #global.node.uid + ". Contentpages without url can't create and generate."))$
   $CMS_SET(#global.stopGenerate,true)$
$CMS_END_IF$
$CMS_SET(pageName, #global.page.getDisplayName(#global.language))$
$CMS_SET(void, attributes.put("name", {localeAbbr: if(pageName.toString() != null, pageName, "")}))$
$CMS_SET(void, attributes.put("meta_title", {localeAbbr: if(!pt_metaTitle.isEmpty, pt_metaTitle.convert2, "")}))$
$CMS_SET(void, attributes.put("meta_description", {localeAbbr: if(!pt_metaDescription.isEmpty, pt_metaDescription.convert2, "")}))$
$CMS_SET(void, attributes.put("meta_keywords", {localeAbbr: if(!pt_metaKeywords.isEmpty, pt_metaKeywords.convert2, "")}))$
$CMS_SET(void, json.put("localizedAttributes", attributes))$

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.

Ermittlung der redaktionellen Inhalte. 

$CMS_SET(blocks, [])$
$CMS_VALUE(#global.page.body("content_top"))$
$CMS_SET(contentTopBlocks, [])$
$CMS_SET(void, contentTopBlocks.addAll(blocks))$

$CMS_SET(blocks, [])$
$CMS_VALUE(#global.page.body("content_body"))$
$CMS_SET(contentBodyBlocks, [])$
$CMS_SET(void, contentBodyBlocks.addAll(blocks))$

$CMS_SET(resultingBlocks, [])$
$CMS_SET(void, resultingBlocks.addAll(contentTopBlocks))$
$CMS_SET(void, resultingBlocks.addAll(contentBodyBlocks))$
$CMS_SET(void, json.put("blocks", resultingBlocks))$

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.

Erzeugung der Block-Referenzen. 

$CMS_SET(placeholder, {:})$
$CMS_SET(contentTopPlaceholder, "")$

$CMS_IF(!contentTopBlocks.isEmpty())$
   $CMS_FOR(contentTopBlock, contentTopBlocks)$
      $CMS_SET(contentTopPlaceholder, contentTopPlaceholder + "{{ fsSpyCmsBlock({name: '" + contentTopBlock.get("block_name") + "'}) }}\n")$
   $CMS_END_FOR$
$CMS_END_IF$

$CMS_SET(contentBodyPlaceholder, "")$
$CMS_IF(!contentBodyBlocks.isEmpty())$
   $CMS_FOR(contentBodyBlock, contentBodyBlocks)$
      $CMS_SET(contentBodyPlaceholder, contentBodyPlaceholder + "{{ fsSpyCmsBlock({name: '" + contentBodyBlock.get("block_name") + "'}) }}\n")$
   $CMS_END_FOR$
$CMS_END_IF$

$-- Placeholders values have to exist in Spryker for synchronization purposes, therefore allowing even empty placeholder values for online CaaS --$
$CMS_IF(!contentTopPlaceholder.isEmpty() || #global.isRelease())$
   $CMS_SET(void, placeholder.put("content_top", {localeAbbr: contentTopPlaceholder}))$
$CMS_END_IF$
$CMS_IF(!contentBodyPlaceholder.isEmpty() || #global.isRelease())$
   $CMS_SET(void, placeholder.put("content_body", {localeAbbr: contentBodyPlaceholder}))$
$CMS_END_IF$

$CMS_SET(void, json.put("placeholder", placeholder))$
$CMS_VALUE(json.toJSON)$

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.

Twig-Template fs-content-page.twig. 

{% extends template('page-layout-main') %}

{% define data = {
   title: _view.pageTitle | default('global.spryker.shop' | trans),
   metaTitle: _view.pageTitle | default('global.spryker.shop' | trans),
   metaDescription: _view.pageDescription | default(''),
   metaKeywords: _view.pageKeywords | default('')
} %}

{% block breadcrumbs %}{% endblock %}

{% block title %}
   <!-- CMS_PLACEHOLDER : "content-top" -->
   <div class="cms-page__title">
      {{ fsSpyCms('content_top') | raw }}
   </div>
{% endblock %}

{% block content %}
   <!-- CMS_PLACEHOLDER : "content-body" -->
   <div class="cms-page__content">
      {{ fsSpyCms('content_body') | raw }}
   </div>
{% endblock %}

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:

Ausgabekanal der Seitenvorlage magazine_detail_page. 

$CMS_SET(json, {:})$
$CMS_IF(#global.pageParams.data.size > 0)$
   $CMS_SET(previewId, previewId(element:#global.node))$
   $CMS_SET(void, json.put("previewId", "" + previewId))$
   $CMS_SET(void, json.put("template_name", pt_cmsPageTemplateName))$
   $CMS_SET(void, json.put("template_path", "@Cms/templates/fs-content-page/fs-content-page.twig"))$
   $CMS_SET(void, json.put("pagetype", "cmspage"))$
   $CMS_SET(void, json.put("is_active", "1"))$
   $CMS_SET(void, json.put("store_names", [ps_activeStore]))$
   $CMS_SET(void, json.put("is_searchable", "1"))$

   $CMS_IF(#global.dataset.formData.tt_page_identifier != null && !#global.dataset.formData.tt_page_identifier.isEmpty())$
      $CMS_SET(void, json.put("identifier", #global.dataset.formData.tt_page_identifier))$
   $CMS_ELSE$
      $CMS_SET(void, #global.logError("Missing page identifier for magazine detail page with entity id '" + #row.id + "'. Magazine detail pages without a page identifier can't be generated."))$
      $CMS_SET(#global.stopGenerate, true)$
   $CMS_END_IF$

   $CMS_SET(locale, #global.language.getLocale())$
   $CMS_SET(localeAbbr, locale.getLanguage() + "_" + locale.getCountry())$

   $CMS_SET(attributes, {:})$
   $CMS_SET(set_entityUrl, #global.dataset.formData.tt_url.convert2)$
   $CMS_IF(set_entityUrl != null && !set_entityUrl.isEmpty())$
      $CMS_SET(url, "/" + locale.getLanguage() + if(!set_entityUrl.startsWith("/"), "/") + set_entityUrl)$
      $CMS_SET(void, attributes.put("url", {localeAbbr: url}))$
   $CMS_ELSE$
      $CMS_SET(void,#global.logError(
         "Missing url for contentpage " + #global.node.uid + "_" + global.dataset.entity.fs_id + ". Contentpages without url can't create and generate."))$
      $CMS_SET(#global.stopGenerate,true)$
   $CMS_END_IF$

   $CMS_SET(pageName, #global.dataset.formData.tt_title.convert2)$
   $CMS_SET(void, attributes.put("name", {localeAbbr: if(pageName.toString() != null, pageName, "")}))$
   $CMS_SET(void, attributes.put("meta_title", {localeAbbr: ""}))$
   $CMS_SET(void, attributes.put("meta_description", {localeAbbr: ""}))$
   $CMS_SET(void, attributes.put("meta_keywords", {localeAbbr: ""}))$
   $CMS_SET(void, json.put("localizedAttributes", attributes))$

   $CMS_VALUE(#global.page.body("container"))$
$CMS_END_IF$

$CMS_VALUE(json.toJSON)$

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.

Ermittlung der redaktionellen Inhalte. 

$CMS_SET(blocks, [])$

$CMS_RENDER(template: "magazine_intro_block_render_template")$
$CMS_SET(contentTopBlocks, [])$
$CMS_SET(void, contentTopBlocks.addAll(blocks))$

$CMS_SET(blocks, [])$
$CMS_VALUE(tt_sections)$
$CMS_SET(contentBodyBlocks, [])$
$CMS_SET(void, contentBodyBlocks.addAll(blocks))$

$CMS_SET(resultingBlocks, [])$
$CMS_SET(void, resultingBlocks.addAll(contentTopBlocks))$
$CMS_SET(void, resultingBlocks.addAll(contentBodyBlocks))$
$CMS_SET(void, json.put("blocks", resultingBlocks))$

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.

Erzeugung der Block-Referenzen. 

$CMS_SET(placeholder, {:})$
$CMS_SET(contentTopPlaceholder, "")$

$CMS_IF(!contentTopBlocks.isEmpty())$
   $CMS_FOR(contentTopBlock, contentTopBlocks)$
      $CMS_SET(contentTopPlaceholder, contentTopPlaceholder + "{{ fsSpyCmsBlock({name: '" + contentTopBlock.get("block_name") + "'}) }}\n")$
   $CMS_END_FOR$
$CMS_END_IF$

$CMS_SET(contentBodyPlaceholder, "")$
$CMS_IF(!contentBodyBlocks.isEmpty())$
   $CMS_FOR(contentBodyBlock, contentBodyBlocks)$
      CMS_SET(contentBodyPlaceholder, contentBodyPlaceholder + "{{ fsSpyCmsBlock({name: '" + contentBodyBlock.get("block_name") + "'}, isContentEditable = false) }}\n")$
   $CMS_END_FOR$
$CMS_END_IF$

$-- Placeholders values have to exist in Spryker for synchronization purposes, therefore allowing even empty placeholder values for online CaaS --$
$CMS_IF(!contentTopPlaceholder.isEmpty() || #global.isRelease())$
   $CMS_SET(void, placeholder.put("content_top", {localeAbbr: contentTopPlaceholder}))$
$CMS_END_IF$
$CMS_SET(void, placeholder.put("content_body", {localeAbbr: contentBodyPlaceholder}))$

$CMS_SET(void, json.put("placeholder", placeholder))$
$CMS_SET(void, json.put("previewId", "" + previewId()))$

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.

ContentSelects im Ausgabekanal des Absatzes. 

<CMS_HEADER>
   <CMS_FUNCTION name="contentSelect" resultname="fr_st_teasers_descending">
      <CMS_PARAM name="schema" value="magazine" />
      <QUERY entityType="magazine_articles">
         <ORDERCRITERIA attribute="date" descending="1" />
      </QUERY>
   </CMS_FUNCTION>

   <CMS_FUNCTION name="contentSelect" resultname="fr_st_teasers_ascending">
      <CMS_PARAM name="schema" value="magazine" />
      <QUERY entityType="magazine_articles">
         <ORDERCRITERIA attribute="date" descending="0" />
      </QUERY>
   </CMS_FUNCTION>
</CMS_HEADER>

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.

Definition diverser Informationen im Ausgabekanal des Absatzes. 

$CMS_SET(block,{:})$

$-- Defining general block data --$
$CMS_SET(void, block.put("previewId", "" + previewId()))$
$CMS_SET(void, block.put("active", "1"))$
$CMS_SET(void, block.put("store_names", [ps_activeStore]))$
$CMS_SET(void, block.put("template_name", "fs_molecule_block"))$
$CMS_SET(void, block.put("template_path", "@CmsBlock/template/fs_molecule_block.twig"))$

$CMS_SET(set_pageType, json.get("pagetype"))$

$-- Add block name attribute to block object (page type dependent) --$
$CMS_RENDER(template: "block_name_render", rt_pageType: set_pageType, rt_blockObject: block)$

$-- Add additional block attributes to block object (page type dependent) --$
$CMS_RENDER(template: "additional_block_attributes_render", rt_pageType: set_pageType, rt_blockObject: block)$

$-- Defining placeholder data of the block --$
$CMS_SET(placeholders,{:})$
$CMS_SET(void, block.put("placeholder",placeholders))$

Daran anschließend erfolgt in zwei Schritten die Ermittlung der Teaser-Informationen. Sie setzen sich aus einem Titel, einem Bild, einem Text und einem Verweis zusammen und werden pro Datensatz im Array teaser gespeichert.

Der erste Schritt berücksichtigt ausschließlich die Informationen der Featured Article, die sich im Formular der Übersichtsseite definieren lassen. Der zweite Schritt basiert auf der Ergebnismenge des entsprechenden ContentSelects und umfasst somit jeweils alle Magazinartikel. In beiden Fällen wird die Formatvorlage magazine_teaser_render referenziert, deren Ausgabekanal lediglich die Auswertung der für die Teaser zur Verfügung stehenden Eingabekomponenten beinhaltet. Die in den beiden Schritten ermittelten Informationen werden in den Arrays featuredTeasers und teasers gespeichert.

Ermittlung der Teaser-Daten im Ausgabekanal des Absatzes. 

$CMS_SET(featuredTeasers, [])$
$CMS_FOR(for_featuredArticle, st_featuredArticles.values)$
   $CMS_SET(teaser,{:})$
   $CMS_RENDER(template: "magazine_teaser_render", rt_entity: for_featuredArticle.entity, rt_teaser: teaser)$
   $CMS_SET(void, featuredTeasers.add(teaser))$
$CMS_END_FOR$

$CMS_SET(teasers, [])$
$CMS_FOR(for_teaser, #global.context.getVariableValue("fr_st_teasers_"+st_sortingOrder.key))$
   $CMS_SET(teaser,{:})$
   $CMS_RENDER(template: "magazine_teaser_render", rt_entity: for_teaser, rt_teaser: teaser)$
   $CMS_SET(void, teasers.add(teaser))$
$CMS_END_FOR$

Das Array data beinhaltet die redaktionellen Inhalte. Ihm werden die zuvor ermittelten Teaser-Daten hinzugefügt. Der Absatz wird Spryker-seitig durch das Molekül fs-magazine-overview 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. Da die Übersichtsseite auf einer dynamischen Inhaltsseite basiert, handelt es sich bei der zugehörigen Seitenvorlage um die contentpage.

Verarbeitung der redaktionellen Inhalte im Ausgabekanal des Absatzes. 

$CMS_SET(data, {:})$
$CMS_SET(void, data.put("moleculename", "fs-magazine-overview"))$
$CMS_SET(void, data.put("featuredTeasers", featuredTeasers))$
$CMS_SET(void, data.put("teasers", teasers))$

$CMS_SET(locale, #global.language.getLocale())$
$CMS_SET(localeAbbr, locale.getLanguage() + "_" + locale.getCountry())$
$CMS_SET(localizedData, {:})$
$CMS_SET(void, localizedData.put(localeAbbr, data))$
$CMS_SET(void, block.put("data", localizedData))$

$CMS_IF(#global.is("WEBEDIT") && !isSet(caas_preview_generation))$
   $CMS_VALUE(block.toJSON)$
$CMS_ELSE$
   $CMS_SET(void, blocks.add(block))$
$CMS_END_IF$

Sowohl die Magazinartikel als auch die Übersichtsseite basieren auf dynamischen Inhaltsseiten und werden daher Spryker-seitig durch das Twig-Template fs-content-page.twig dargestellt. Dieses enthält die Placeholder content_top und content_body, welche die ihnen zugeordneten CMS Blöcke referenzieren. Auf diesem Weg werden für die Intro-Daten der Magazinartikel das Molekül fs-magazine-intro.twig und für die Teaser-Informationen der Übersichtsseite das Molekül fs-magazine-overview.twig aufgerufen. Das Molekül fs-magazine-overview.twig referenziert seinerseits das Molekül fs-magazine-teaser.twig, das die Teaser-Informationen eines einzelnen Magazinartikels bereitstellt. Alle drei Moleküle steuern ihrerseits die Ausgabe der redaktionellen Inhalte.

Die Ausgabe der übrigen Absätze der Magazinartikel erfolgt über die ihnen zugehörigen Twig-Templates. Sowohl die Templates dieser Absätze als auch die Moleküle für die Magazinartikel und die Übersichtsseite sind ein Bestandteil des in der Auslieferung enthaltenen Spryker-Moduls firstspirit-reference-components.

Ebenso wie bei den Molekülen des Shoppable Video-Absatzes und des Banners wird innerhalb der drei Twig-Templates für die Magazinartikel und die Übersichtsseite zunächst der Name des Moleküls definiert und anschließend das fsBlockData-Objekt erzeugt. Es ermöglicht den Zugriff auf die strukturierten Daten, die im Ausgabekanal der FirstSpirit-Tabellenvorlage definiert sind. Das fsBlockData-Objekt und das FirstSpirit-seitige JSON-Objekt besitzen somit jeweils dieselbe Struktur.

Der Block body beschreibt in den Molekülen jeweils die Ausgabe der redaktionellen Inhalte. Diese entsprechen im Template für die Magazinartikel deren Intro-Daten, die sich aus einem Titel, einem Subtitel und einem Banner zusammensetzen. Im Template für die Übersichtsseite handelt es sich um die Teaser-Daten der Magazinartikel, die aus einem Bild, einem Titel, einem Text und einem Verweis bestehen und mithilfe des Moleküls für die Teaser bereitgestellt werden.

Die folgenden Code-Beispiele zeigen die Inhalte der Moleküle.

Twig-Template fs-magazine-intro.twig. 

{% extends model('component') %}

{% define config = {
    name: 'fs-magazine-intro'
} %}

{% define data = {
    fsBlockData: [],
} %}

{% block body %}
   <article class="magazine">
      <header>
         <h1>{{ data.fsBlockData.title }}</h1>
         {% if data.fsBlockData.subtitle is defined %}
            <h2>{{ data.fsBlockData.subtitle }}</h2>
         {% endif %}
         {% if data.fsBlockData.banner.imageUrl is defined %}
            <figure class="picture picture-responsive">
               <img class="img-fluid" src="{{ data.fsBlockData.banner.imageUrl | raw }}"
                  {% if  data.fsBlockData.banner.previewId is defined %}
                     data-preview-id="{{ data.fsBlockData.banner.previewId }}"
                  {% endif %}
                  data-tpp-context-image-resolution="MAGAZINE_ARTICLE_BANNER">
            </figure>
         {% endif %}
      </header>
   </article>
{% endblock %}

Twig-Template fs-magazine-overview.twig. 

{% extends model('component') %}

{% define config = {
    name: 'fs-magazine-overview'
} %}

{% define data = {
    fsBlockData: [],
} %}

{% block body %}
   {% if isFsPreview() %}
      <div style="padding-top: 24px;"></div>
   {% endif %}
   {% if data.fsBlockData.featuredTeasers is not empty %}
      <h2 style="text-align: left;">Featured</h2>
   {% endif %}

   <div class="featured-magazine-teasers">
      {% for teaser in data.fsBlockData.featuredTeasers %}
         {% include molecule('fs-magazine-teaser', 'FirstSpiritReferenceComponents') with {
            data: {
               fsBlockData: teaser
            }
         } only %}
      {% endfor %}
   </div>

   {% if data.fsBlockData.featuredTeasers is not empty %}
      <hr class="magazine-featured-divider">
   {% endif %}

   <div class="magazine-teasers">
      {% for teaser in data.fsBlockData.teasers %}
         {% include molecule('fs-magazine-teaser', 'FirstSpiritReferenceComponents') with {
            data: {
               fsBlockData: teaser
            }
         } only %}
      {% endfor %}
   </div>
{% endblock %}

Twig-Template fs-magazine-teaser.twig. 

{% extends model('component') %}

{% define config = {
   name: 'fs-magazine-teaser'
} %}

{% define data = {
   fsBlockData: [],
} %}

{% block body %}
   <article class="magazine-teaser"
      {% if data.fsBlockData.previewId is defined %}
         data-preview-id="{{ data.fsBlockData.previewId }}"
      {% endif %}>
      {% set cmsPageUrl = getCmsPageUrl(data.fsBlockData.page_identifier) %}

      {% if cmsPageUrl is not null %}
         <a href="{{ cmsPageUrl }}">
      {% endif %}

         {% if data.fsBlockData.picture.imageUrl is defined %}
            <figure class="picture picture-responsive">
               <img src="{{ data.fsBlockData.picture.imageUrl }}"
                  {% if  data.fsBlockData.picture.previewId is defined %}
                     data-preview-id="{{ data.fsBlockData.picture.previewId }}"
                  {% endif %}
                  data-tpp-context-image-resolution="CONTENT_IMAGE">
            </figure>
         {% endif %}
         <h3>{{ data.fsBlockData.title | raw }}</h3>
         <p>{{ data.fsBlockData.text | raw }}</p>

      {% if cmsPageUrl is not null %}
         </a>
      {% endif %}
   </article>
{% endblock %}

Die Navigationen des Spryker B2C Demo Shops werden in FirstSpirit über die Seitenvorlage navigation_extension abgebildet, auf deren Basis pro Navigation automatisch eine globale Seite erzeugt wird. Sie besitzt eine FS_CATALOG-Eingabekomponente, die mithilfe der Absatzvorlage navigation_node_reference die Startknoten aller in FirstSpirit gepflegten Menüpunkte referenziert. Jeder dieser Startknoten entspricht einem Strukturordner, der innerhalb eines Bearbeitungsdialogs im ContentCreator auszuwählen ist. Dafür besitzt die Hauptnavigation im ContentCreator einen Button, der die Ergänzung neuer Menüpunkte in der ersten Ebene der Navigation ermöglicht. Enthält ein referenzierter Strukturordner weitere Unterordner, werden diese automatisch als Unterpunkte des neuen Menüpunkts interpretiert.

Abbildung 28. Button zur Erweiterung der Navigation

Die im Referenzprojekt enthaltene globale Seite navigation_extension ermöglicht die Erweiterung der Hauptnavigation im ContentCreator. Der Navigation lassen sich Menüpunkte in der ersten Ebene hinzufügen, die jeweils einem Strukturordner entsprechen und als Startknoten dienen. Die Unterordner eines solchen Strukturordners werden automatisch als Unterpunkte des neuen Menüpunkts interpretiert.

Für alle neuen Startknoten wird der FS_CATALOG-Eingabekomponente der globalen Seite jeweils ein auf der Absatzvorlage navigation_node_reference basierender Eintrag hinzugefügt. Die Absatzvorlage enthält ihrerseits eine FS_REFERENCE-Eingabekomponente, die der Referenzierung des jeweiligen Menüpunkts dient.

In ihrem Ausgabekanal enthält die Absatzvorlage darüber hinaus die Navigationsfunktion fr_mainNav. Ausgehend vom ausgewählten Strukturordner erzeugt diese Funktion für ihn und die in ihm enthaltenen Unterordner die Teilnavigation für den neuen Menüpunkt. Alle diese Teilnavigationen der einzelnen Menüpunkte werden mithilfe der technischen Seitenvorlage navigations zusammengefasst und an den CaaS übertragen.

Zusätzlich zur globalen Seite enthält das Referenzprojekt die technische Seitenreferenz navigations. Diese dient der Übertragung aller in FirstSpirit durchgeführten Navigationsänderungen in den CaaS.

Mithilfe des Skripts get_navigation_gca_pages ermittelt die Seitenreferenz alle globalen Seiten, die auf der Seitenvorlage navigation_extension basieren. Die globalen Seiten bilden die über den ContentCreator erweiterbaren Navigationen in FirstSpirit ab. Innerhalb des Referenzprojekts handelt es sich dabei um die Hauptnavigation des Spryker B2C Demo Shops in der Desktop- und in der mobilen Version.

Jede dieser globalen Seiten enthält eine FS_CATALOG-Eingabekomponente, die mithilfe der Absatzvorlage navigation_node_reference die Startknoten aller in FirstSpirit gepflegten Menüpunkte referenziert. Die Absatzvorlage erzeugt ihrerseits für jeden dieser Startknoten eine Teilnavigation. Die technische Seitenreferenz fasst alle diese Teilnavigationen zusammen und erzeugt ein JSON-Dokument, in dem alle in FirstSpirit erweiterbaren Navigationen enthalten sind.

Für die Freigabe der vorgenommenen Navigationsänderungen stellt das Referenzprojekt den Arbeitsablauf Freigabe der Navigation bereit, für dessen Ausführung das Freigabe-Recht erforderlich ist. Der Arbeitsablauf führt lediglich die Freigabe, jedoch keine Publikation der zugehörigen globalen Seite durch. Gleichzeitig stößt er ein Skript an, das die Übertragung der technischen Seitenreferenz in den Preview CaaS sicherstellt. Die Publikation der Anpassungen und ihre Übertragung in den Online CaaS erfolgt erst im Rahmen einer Vollgenerierung.

Zusätzlich zu den beschriebenen Vorlagen in FirstSpirit wird Spryker-seitig die Anpassung der folgenden Twig-Templates vorausgesetzt, um die Erweiterung der Hauptnavigation des Spryker B2C Demo Shops im ContentCreator zu ermöglichen.

Die Twig-Templates bilden Spryker-seitig die Hauptnavigation in der Desktop- und in der mobilen Version ab. Sie referenzieren die einzelnen Menüpunkte und steuern ihre Darstellung in der Vorschau und im Live-Stand. Mithilfe der Anpassungen erhalten beide Versionen der Hauptnavigation im ContentCreator einen Button, der die Ergänzung weiterer Menüpunkte ermöglicht.

Besteht der Wunsch, andere Navigationen im ContentCreator zu bearbeiten, ist ausschließlich eine Anpassung der zugehörigen Twig-Templates erforderlich. Das Kapitel Navigationspflege erläutert die dafür notwendigen Schritte.

Bei der Erstellung von Inhaltsseitenverweisen ist Redakteuren kein Unterschied zwischen statischen und dynamischen Seiten ersichtlich. Da statische Seiten jedoch standardmäßig keine URL besitzen, wäre ihre Referenzierung generell nicht möglich. Die Projekteinstellungen stellen daher eine Möglichkeit bereit, ihnen eine URL zuzuweisen. Sie besitzen dafür den FS_CATALOG ps_staticLinks, der mithilfe des Buttons Statische Seiten Templates Import befüllt wird.

Der Button Statische Seiten Templates Import führt die Executable ProjectPropertiesStaticPageUrlListExecutable aus, die den Inhalt des Vorlagenordners static_pages ermittelt. Für jede in dem Ordner enthaltene Vorlage fügt sie dem FS_CATALOG einen Eintrag auf Basis der technischen Absatzvorlage static_page_url hinzu. Jeder dieser Einträge besitzt eine Referenz auf die jeweilige Vorlage sowie ein sprachabhängiges Feld für die zu definierende relative URL.

Für die Erzeugung der Einträge und die automatische Referenzierung der Vorlagen innerhalb dieser Einträge besitzt der Button die folgenden Parameter, die innerhalb des Referenzprojekts entsprechend vordefiniert sind:

Um Inhaltsseitenverweise auf statische Seiten zu ermöglichen, müssen die in den Projekteinstellungen definierten URLs in den Verweisvorlagen verfügbar sein. Der Ausgabekanal der Projekteinstellungen enthält daher den folgenden Code, mit dem die URL einer Vorlage jeweils in der Variablen set_ps_staticLinks gespeichert wird.

Ausgabekanal der Projekteinstellungen. 

$CMS_SET(set_ps_staticLinks,{:})$
$CMS_FOR(for_staticLink,ps_staticLinks.filter(x->!x.item.st_pageTemplate.isEmpty))$
   $CMS_SET(void, set_ps_staticLinks
      .put(
         for_staticLink.item.st_pageTemplate.get.uid,
         for_staticLink.item.st_url.convert2
      )
   )$
$CMS_END_FOR$
$CMS_SET(set_ps_contentPageList,["contentpage"])$

Innerhalb des Referenzprojekts wird die Variable im Ausgabekanal des Inhaltsseitenverweises abgefragt. Auf diesem Weg müssen Redakteure bei der Auswahl eines Verweisziels nicht zwischen statischen und dynamischen Inhaltsseiten unterscheiden können.

Code-Ausschnitt des Inhaltsseitenverweises. 

$CMS_SET(set_pageUid,lt_pageRef.get().page.template.uid)$
$CMS_IF(set_pageUid == "contentpage")$
[...]
$CMS_ELSIF(!set_ps_staticLinks.isEmpty)$
   $CMS_IF(set_ps_staticLinks.containsKey(set_pageUid) && !set_ps_staticLinks.get(set_pageUid).isEmpty)$
      $CMS_SET(void, set_link.put("url", set_ps_staticLinks.get(set_pageUid)))$
      $CMS_SET(void, set_link.put("type","static"))$
      [...]
   $CMS_END_IF$
   [...]
$CMS_END_IF$