Grundlagen & Architektur von strapi - WEBSALE Dokumentation

Auf dieser Seite werden die grundlegenden Konzepte und die Architektur von strapi erklärt. Ziel ist es, ein Verständnis dafür zu schaffen, wie strapi als Headless-CMS aufgebaut ist, welche Rolle der API-First-Ansatz spielt und wie Inhalte aus Strapi in den WEBSALE Shop ausgeliefert werden. Damit dient die Seite als Basis, um die weiteren Bereiche der Dokumentation (insbesondere Content-Typen, Komponenten und die Pflege von Inhalten) besser einordnen und sicher anwenden zu können.

Grundlagen von strapi

Verständnis der Strapi Architektur

In strapi gibt es zwei Hauptbereiche, die für die Verwaltung und Strukturierung von Inhalten zuständig sind: der Content-Manager und der Content-Type Builder. Diese Bereiche ergänzen sich und bieten zusammen ein leistungsstarkes Werkzeugset für Content-Management und -Design.

Content-Type Builder & Content-Manager

Content-Type Builder: Definition von Strukturen und Komponenten

Dieser Bereich wird verwendet, um die Strukturen zu definieren, in denen die Inhalte später eingegeben werden. Hier wird festgelegt, welche Felder und Datentypen die Inhalte haben sollen und die Komponenten erstellt, die dann im Content-Manager gefüllt werden.

Strukturen definieren: Der Content-Type Builder wird genutzt, um die Schemata für Sammlungen und Einzel-Einträge zu erstellen und zu bearbeiten. Diese Schemata bestimmen, welche Datenfelder und Datentypen verfügbar sind und wie die Eingabemasken im Content-Manager aussehen.
Komponenten gestalten: Eine weitere wichtige Funktion des Content-Type-Builders ist das Erstellen von wiederverwendbaren Komponenten. Diese Komponenten können in verschiedenen Teilen des Projekts genutzt werden und fördern dadurch die Konsistenz und Wiederverwendbarkeit in der Entwicklung.

Content-Manager: Verwaltung von Inhalten

Hier werden die Inhalte, die in einem Strapi-Projekt erstellt und gepflegt werden, direkt verwaltet. Dies ist der Ort, an dem Benutzer tatsächlich Inhalte wie Texte, Bilder und andere Medien hinzufügen, die auf der Storefront angezeigt werden.

Inhalte verwalten: Im Content-Manager werden alle Inhalte wie Texte, Bilder, Videos und andere Medien, die direkt auf der Storefront sichtbar sind, verwaltet. Benutzer können hier neue Inhalte erstellen, bestehende bearbeiten oder nicht mehr benötigte Inhalte löschen.
Daten organisieren: Der Content-Manager ermöglicht das systematische Organisieren von Inhalten in Sammlungen und Einzel-Einträgen. Diese Struktur hilft, Inhalte leichter auffindbar und verwaltbar zu machen und unterstützt eine klare Hierarchie und Ordnung innerhalb des Systems.

Zusammenspiel von Content-Manager und Content-Type Builder

Der Content-Manager und der Content-Type-Builder arbeiten Hand in Hand:

Vom Builder zum Manager: Im Content-Type-Builder erstellte Strukturen und Komponenten dienen als Grundlage für die Inhaltsverwaltung im Content-Manager. Dies sichert eine kohärente Datenhandhabung und effiziente Content-Verwaltung.
Anpassungsfähigkeit und Dynamik: Durch die flexible Struktur des Content-Type Builders können Anpassungen vorgenommen werden, die dann im Content-Manager reflektiert werden, ohne dass Inhalte verloren gehen oder umständlich neu erstellt werden müssen.

Sammlungen, Einzel-Einträge und Komponenten

Sammlungen

Sammlungen in Strapi sind Strukturen, die dazu dienen, mehrere ähnliche Daten unter einem Dach zu verwalten. Sie eignen sich hervorragend, um Inhaltsseiten, mehrere Stellenanzeigen oder auch Blogartikel zu organisieren. Eine Sammlung fungiert somit als zentraler Punkt, dem sie ähnliche Inhalte oder Elemente unterordnen können. Sammlungen stehen sowohl unter dem Content-Manager, wie auch dem Content-Type-Builder zur Verfügung. Mehr Informationen zu Sammlungen gibt es hier.

Einzel-Einträge

Einzel-Einträge sind spezifische Inhalts-Elemente, die nicht unbedingt Teil einer wiederholbaren Sammlung sind. Sie können für spezielle Seiten oder spezifische Inhaltsblöcke verwendet werden, wie zum Beispiel ein Banner oder ein Produktslider auf der Startseite. Einzel-Einträge stehen sowohl unter dem Content-Manager, wie auch dem Content-Type-Builder zur Verfügung. Mehr Informationen zu Einzel-Einträgen gibt es hier.

Content-Typen zum Erstellen neuer Sammlungen & Einzel-Einträge

Content-Typen sind die Bausteine für die Strukturierung von Inhalten innerhalb von Strapi. Sie definieren, wie Daten in Sammlungen und Einzel-Einträgen organisiert sind. Neue Content-Typen und somit neue Inhalte unterhalb von Sammlungen und Einzel-Einträgen werden im Content-Type Builder erstellt.

Zum Anlegen neuer Content-Typen wird die Unterstützung eines WEBSALE-Mitarbeiters aus der Systemadministration benötigt. Dieser muss die neuen Content-Typen in der Konfiguration des Strapi-Connectors hinterlegen.

Komponenten

Komponenten in Strapi sind wiederverwendbare Bausteine, die in verschiedenen Teilen des Projekts genutzt werden können, um Inhalte konsistent und effizient zu gestalten. Mehr Informationen zu Komponenten gibt es hier.

SEO-Meta-Daten für CMS-Seiten (Meta-Info-Plugin)

Für CMS-Seiten steht im Standard das Meta-Info-Plugin zur Verfügung. Es ist auf jeder CMS-Seite vorhanden und stellt dort feste, vorgegebene Felder für die SEO-Angaben bereit: SEO-URL, Meta-Title, Meta-Description und Robots. Diese Felder müssen nicht selbst angelegt werden. Sie gehören nicht zu den frei gestaltbaren Content-Typen, sondern werden vom Plugin verwaltet. Dadurch sind sie auf jeder Seite identisch vorhanden und können beim Bearbeiten der Content-Typen nicht versehentlich verändert oder gelöscht werden. So ist sichergestellt, dass jede in Strapi angelegte Seite zuverlässig über eine SEO-URL verfügt und darüber aufrufbar ist. Die eingetragenen Werte werden an den Shop übergeben. Der Shop setzt Meta-Title und Meta-Description über denselben internen Weg wie bei Kategorie- und Produktseiten. Sie stehen deshalb wie gewohnt im Template über die Funktionen $wsViews.metaTitle() und $wsViews.metaDescription() bereit. Im Template erscheinen alle Robots-Angaben gesammelt unter $wsViews.current.robotOptions.

Der Shop setzt diese Angaben, er gibt sie nicht von sich aus im HTML aus. Für Meta-Title und Meta-Description erledigt das üblicherweise das Basis-Template. Die Robots-Angaben und die Alternativsprachen (hreflang) rendert das Basis-Template im Auslieferungszustand dagegen nicht. Wer sie braucht, muss sie im CMS-Seitentemplate selbst ausgeben, siehe Template Theme.Der Konfigurationsknoten seoMetaData und dort insbesondere viewSchemes betrifft die SEO-Texte statischer Views. Für CMS-Seiten wird er nicht ausgewertet. Deren SEO-Angaben kommen ausschließlich aus dem Meta-Info-Plugin.

Weiterführende Informationen:

Die Bedeutung der einzelnen SEO-Felder ist unter Komponenten & Sammlungen in strapi im Abschnitt „Meta-Information“ beschrieben.
Die Pflege der Meta-Angaben je Seite ist unter Inhalte anpassen in strapi anhand von Beispielen dargestellt.
Wie der Shop aus diesen Angaben eine aufrufbare Seite macht, steht im nächsten Abschnitt.

Auslieferung von CMS-Seiten in den Shop

Statische Inhaltsseiten (beispielsweise AGB, Impressum, Zahlungsarten, „Über uns”) werden in strapi gepflegt und als JSON-Dokumente in den Shop übertragen. Der Shop registriert dafür eigene SEO-URLs und rendert alle diese Seiten mit einem Template.

strapi (Redaktion)
   │   Content-Typen + Meta-Info-Plugin (SEO-Felder)
   ▼
websale-sync  ──►  Dateigruppe "system"
                     json/<subshopId>/index-mapping.json   ← Seitenverzeichnis
                     json/<subshopId>/<…>/<dokument>.json  ← ein Dokument je Seite
   │
   ├─►  SEO-URL-Generator   registriert die SEO-URLs (View-Controller "CmsPage")
   │
   └─►  Shop           Aufruf der SEO-URL → lädt das Dokument → rendert cms_tpl.htm
                       Das Dokument steht im Template als $wsCmsPage bereit

Damit eine Seite erscheint, müssen zwei Dinge zusammenpassen: die SEO-URL muss registriert sein (das macht der SEO-URL-Generator anhand des Seitenverzeichnisses) und das Seitendokument muss im Objektspeicher liegen. Fehlt eines von beidem, liefert der Shop einen 404-Fehler.

Der SEO-URL-Generator

SEO-URLs entstehen nicht beim Seitenaufruf, sondern in einem eigenen Prozess. Der SEO-URL-Generator (Programm seogenerator) durchläuft dabei die Ressourcen eines Subshops durch und schreibt für jede eine SEO-URL in den URL-Bestand des Shops. Er ist nicht CMS-spezifisch. Dieselbe Mechanik registriert auch die URLs von Produkten und Kategorien. Jeder Subshop wird separat verarbeitet.

Ablage in der Dateigruppe `system`

Die Pfade sind fest verdrahtet und nicht konfigurierbar. Es handelt sich um dieselbe Dateigruppe, die Templates über die Ladeoption source: "system" erreicht wird (siehe $wsExternalData).

Datei	Pfad innerhalb der Dateigruppe `system`
Seitenverzeichnis	`json/<subshopId>/index-mapping.json`
Seitendokument	`json/<subshopId>/<file>`

<subshopId> ist die ID des Subshops, beispielsweise deutsch, english, francais. Jeder Subshop hat seinen eigenen Ordner und liest ausschließlich sein eigenes Seitenverzeichnis.
Der Name der Verzeichnisdatei ist über cmsTemplates.mappingFile konfigurierbar (Standard index-mapping.json). Der Ordner json/ ist es nicht.
Die Ordnerstruktur unterhalb von json/<subshopId>/ ist frei. Üblich ist die strapi-Struktur, beispielsweise collections/contentpage/jyllb6ubw0dj62vndr0lh7z1.json.

Der Dateiname hat keine Bedeutung. Er hat keinen Einfluss auf die URL der Seite. Diese steht ausschließlich im Feld url im Seitenverzeichnis bzw. in meta.url des Dokuments.

Welche URL gehört zu welcher Datei

Das Seitenverzeichnis beantwortet diese Frage:

{
  "mappings": [
    {
      "url": "Zahlungsarten",
      "file": "collections/contentpage/jyllb6ubw0dj62vndr0lh7z1.json",
      "subshop": "deutsch",
      "stage": "live"
    },
    {
      "url": "AGB",
      "file": "collections/contentpage/agb1.json"
    }
  ]
}

Feld	Pflicht	Bedeutung
`url`	ja	Die aufrufbare URL der Seite, ohne führenden Schrägstrich. Ist sie leer oder `null`, wird der Eintrag ignoriert.
`file`	ja	Pfad des Dokuments relativ zu `json/<subshopId>/`. Ist er leer, wird der Eintrag ignoriert.
`subshop`	nein	Subshop, dem die Seite gehört. Leer oder fehlend = gilt für jeden Subshop. Steht hier ein anderer Subshop als der lesende, wird der Eintrag übersprungen.
`stage`	nein	`live` oder leer/fehlend = wird veröffentlicht. Jeder andere Wert (beispielsweise `draft` oder `preview`) wird übersprungen.

Bei jedem Durchlauf des SEO-URL-Generators werden die URLs aller passenden Einträge neu registriert und alle bereits registrierten CMS-URLs entfernt, die sich nicht mehr im Verzeichnis befinden. Dadurch verschwindet eine gelöscht oder auf stage:draft gesetzte Seite beim nächsten Erzeugen der SEO-URLs von selbst.

Das Aufräumen findet nur im vollständigen Durchlauf statt. Wird über POST seo/urls/reset eine einzelne Seite neu registriert, werden keine URLs entfernt. Kann das Seitenverzeichnis nicht gelesen werden, bricht der Lauf vorzeitig ab und es werden weder neue URLs registriert noch alte entfernt.Nicht zu verwechseln mit der Option „nicht mehr genutzte URLs löschen” (deleteOld) beim Anstoßen des Laufs: Das Entfernen verschwundener CMS-Seiten passiert unabhängig davon.

Hinweise zur URL

Der Wert aus url wird als fertiger Pfad übernommen. Der Shop fügt lediglich einen Schrägstrich davor hinzu und ergänzt bei Bedarf den abschließenden Schrägstrich. Das hat mehrere Konsequenzen:

Kein führender Schrägstrich. Der Shop setzt ihn selbst. Ein Wert wie "/AGB" führt zu einer doppelten Trennung (//AGB) und damit zu einer nicht erreichbaren Seite.
Der abschließende Schrägstrich wird gemäß Shop-Konfiguration (urls.urls.alwaysEndWithSlash) automatisch ergänzt.
Keine Zeichensatz-Prüfung und keine Normalisierung. Großbuchstaben sind ausdrücklich üblich (AGB, Zahlungsarten).
Die URL-Aufbereitung des Shops greift hier nicht. Von den Einstellungen unter urls.urls wirken auf CMS-URLs nur active und alwaysEndWithSlash (sowie suffixSeparator im Kollisionsfall). lowercase, wordSeparator und die Zeichen-mappings für Umlaute werden nicht angewendet – anders als bei Kategorie- und Produkt-URLs. Aus AGB wird also auch bei lowercase: true der Pfad /AGB.
Die URL wird beim Aufruf exakt verglichen, also inklusive Groß- und Kleinschreibung. /agb findet eine als AGB registrierte Seite nicht.
Sonderzeichen und Leerzeichen müssen bereits kodiert sein. Der Wert wird als bereits kodierter Pfad behandelt und dekodiert. Sauberer ist es, sie in strapi zu vermeiden.
Bereits im Admin Interface manuell gesetzte URLs gewinnen. Existiert für eine Seite eine manuell gesetzte URL, wird der Wert aus dem Seitenverzeichnis stillschweigend ignoriert , ohne Logmeldung. Eine geänderte url bleibt dann wirkungslos.
Bei einer Pfadkollision hängt der Shop suffixSeparator plus eine Zahl an, statt die Registrierung abzubrechen. Die Seite ist dann unter einer unerwarteten URL erreichbar, und es gibt dazu keine Logmeldung. Ältere Pfade derselben Seite werden per 301 auf den aktuellen Pfad umgeleitet.

Weil der Shop nichts normalisiert, muss die URL bereits in strapi so gepflegt werden, wie sie im Browser stehen soll. Das ist Absicht: Seitennamen wie AGB sollen nicht durch eine automatische Kleinschreibung verändert werden.

Das Seitendokument

Jedes Dokument hat die gleiche äußere STruktur, die sogenannte “Hülle”: contentType, meta und fields. Es handelt sich um dieselbe Hülle wie im schema-Format der Sync-Middleware, das unter Migration der strapi-Datenstruktur (Version 5) ausführlich beschrieben ist.

{
  "contentType": "api::contentpage.contentpage",
  "meta": {
    "id": 92,
    "documentId": "jyllb6ubw0dj62vndr0lh7z1",
    "locale": "de",
    "createdAt": "2026-06-26T08:00:00.000Z",
    "updatedAt": "2026-07-16T09:00:00.000Z",
    "publishedAt": "2026-07-16T09:03:00.000Z",
    "url": "Zahlungsarten",
    "metaTitle": "Zahlungsarten",
    "metaDescription": "Beschreibung zu Zahlungsarten",
    "robots": ["noindex", "nofollow"],
    "hreflang": [
      {
        "language": "fr-fr",
        "url": "myshop.fr/paiement",
        "subshopId": "francais",
        "default": false
      }
    ]
  },
  "fields": [
    { "name": "Markup", "type": "richtext", "value": "AGB Content" },
    {
      "name": "content",
      "type": "dynamiczone",
      "value": [
        {
          "component": "elemente.ws-markup",
          "id": 96,
          "fields": [
            { "name": "FullWidth", "type": "boolean", "value": false }
          ]
        }
      ]
    }
  ]
}

Ebene	Inhalt	Wird vom Shop …
`contentType`	Content-Typ der Seite	gelesen, aber nicht ausgewertet
`meta`	strapi-Verwaltungsdaten plus SEO-Block	teilweise ausgewertet, siehe unten
`fields`	Die redaktionellen Inhalte, Struktur frei nach Kunden-Modellierung	unverändert durchgereicht. Der Shop interpretiert hier nichts.

Der Grundsatz hierbei lautet: Die Hülle ist fest, der Inhalt ist frei.
Der Shop garantiert lediglich die Auswertung des SEO-Blocks. Wie fields aussieht, bestimmt allein die Modellierung der Content-Typen in strapi. Wie es dargestellt wird, bestimmt allein das Template.

Es gibt keine vom Shop vorgegebenen Inhaltsblock-Typen. Der Shop kennt keine festen Bausteine wie “Übeschrift” oder “Bild” mit garantierter Bedeutung. Welche Feldnamen und Komponenten es gibt, ergibt sich aus der strapi-Modellierung des jeweiligen Shops und ihre Darstellung ist vollständig Aufgabe des Templates.

Der SEO-Block in `meta`

Diese Felder wertet der Shop aus:

Feld	Typ	Pflicht	Wirkung
`url`	Text	ja für `seo/urls/reset`	Die URL der Seite, ohne führenden Schrägstrich. Im vollständigen Lauf zählt der Wert aus dem Seitenverzeichnis; beim Zurücksetzen einer einzelnen URL über `POST seo/urls/reset` dagegen dieser Wert. Fehlt er dort, wird keine SEO-URL erzeugt. Beide Werte sollten übereinstimmen.
`metaTitle`	Text	empfohlen	Wird als Meta-Title der Seite gesetzt (Browser-Tab, Suchergebnis).
`metaDescription`	Text	optional	Wird als Meta-Description gesetzt.
`robots`	Liste von Texten	optional	Jeder Eintrag wird den Robots-Angaben der Seite hinzugefügt, beispielsweise `["noindex", "nofollow"]`. Einträge, die kein Text sind, werden stillschweigend übersprungen.
`publishedAt`	Zeitstempel oder `null`	ja, für die öffentliche Sichtbarkeit	Steuert Entwurf/Veröffentlicht, siehe unten.

Alle weiteren meta-Felder (id, documentId, locale, createdAt, updatedAt) sind strapi-Verwaltungsdaten. Sie werden nicht ausgewertet, stehen dem Template aber zur Verfügung. meta.hreflang ist Teil der Hülle und steht im Template zur Verfügung, wird aber nicht automatisch in die hreflang-Angaben des Shops übernommen. $wsViews.current.getHreflangAutomatic() liefert für CMS-Seiten nichts. Wer Alternativsprachen ausgeben will, muss sie im Template selbst rendern, siehe Template Theme.

Entwurf und Veröffentlichung

Es gibt zwei voneinander unabhängige Schalter:

stage im Seitenverzeichnis entscheidet, ob die URL überhaupt entsteht. live oder leer → die URL wird registriert. Alles andere → kein Eintrag, die Seite ist nicht adressierbar.
meta.publishedAt im Dokument entscheidet, ob die Seite ausgeliefert wird.

`publishedAt`	Öffentlicher Aufruf	Mit aktiver Testmodus-Session
Zeitstempel gesetzt	Seite wird ausgeliefert	Seite wird ausgeliefert
`null` oder fehlend	404	Seite wird ausgeliefert (Vorschau)

Entwürfe lassen sich also im Shop vorab ansehen, indem der Testmodus aktiviert wird, genau wie bei anderen Vorschau-Inhalten. Siehe Testmodi des Shops ein-/ausschalten.

Es wird nur geprüft, ob ein Wert vorhanden ist, nicht, ob der Zeitpunkt in der Vergangenheit liegt. Ein publishedAt in der Zukunft veröffentlicht die Seite sofort. Eine zeitgesteuerte Veröffentlichung über den Shop ist damit nicht möglich. Sie muss auf der strapi-Seite erfolgen, da strapi das Feld publishedAt erst beim Veröffentlichen setzt.

Konfiguration

Der Konfigurationsknoten cmsTemplates liegt im Bereich content:

{
  "cmsTemplates": {
    "template": "cms_tpl.htm",
    "mappingFile": "index-mapping.json"
  }
}

Parameter	Standard	Bedeutung
`template`	`cms_tpl.htm`	Template, mit dem CMS-Seiten gerendert werden. Pfad relativ zu `templates/views/`.
`mappingFile`	`index-mapping.json`	Name der Verzeichnisdatei in `json/<subshopId>/`

Der Knoten ist ein Singleton und je Subshop überschreibbar. Alle Details unter content.cmsTemplates.

Wenn eine CMS-Seite nicht erscheint

Symptom	Wahrscheinliche Ursache	Prüfen
Die Seite liefert 404	Die SEO-URL ist nicht registriert.	Steht die Seite mit `url` und `file` im Seitenverzeichnis? Passt `subshop` zum aufgerufenen Subshop? Steht `stage` auf `live` oder ist es leer? Sind SEO-URLs überhaupt aktiv (`urls.urls.active`)? Lief der SEO-URL-Generator seit der letzten Änderung?
Keine einzige CMS-Seite ist erreichbar	`cmsPage` fehlt in `urls.urls.generate`, oder es lief noch kein Lauf.	Der SEO-URL-Generator
Die Seite liefert 404, obwohl die URL registriert ist	Das Dokument fehlt, ist leer oder nicht lesbar, oder es ist ein Entwurf.	Liegt die Datei unter `json/<subshopId>/<file>`? Ist `meta.publishedAt` gesetzt? Ist die Datei gültiges JSON (Log-Code `cmsTemplates.jsonParseError`)?
Die Seite ist unter `//AGB` bzw. gar nicht erreichbar	`url` enthält einen führenden Schrägstrich.	Führenden Schrägstrich aus `url` entfernen.
Die Seite ist unter einer URL mit angehängter Zahl erreichbar	Der Pfad kollidiert mit einer bereits registrierten URL.	Kollidierende URL im Admin Interface bzw. im Seitenverzeichnis auflösen.
Eine geänderte `url` wirkt nicht, die Seite bleibt unter der alten Adresse	Für die Seite ist im Admin Interface eine URL manuell gesetzt. Die wird nicht überschrieben, und es gibt dazu keine Logmeldung.	Manuelle URL der Ressource im Admin Interface prüfen, siehe API-Referenz SEO-URLs.
Eine gelöschte Seite ist weiterhin erreichbar	Es lief kein vollständiger Lauf, oder der Lauf brach am Seitenverzeichnis ab.	Log auf `cmsTemplates.generateNoMapping` und `cmsTemplates.generateMappingParseError` prüfen.
Die Seite erscheint, aber ohne Inhalte aus `fields`	Feldname oder Komponenten-Name im Template passt nicht zur strapi-Modellierung.	Template Theme

Die Meldungen des SEO-URL-Generators und des Seitenaufrufs sind im Log-Manager über diese Codes auffindbar:

Log-Code	Bedeutung
`cmsTemplates.generateNoMapping`	Das Seitenverzeichnis konnte nicht gelesen werden. Der Lauf bricht ab.
`cmsTemplates.generateMappingParseError`	Das Seitenverzeichnis ist kein gültiges JSON.
`cmsTemplates.generateSkippedMapping`	Ein Eintrag wurde übersprungen. Die Meldung nennt `url`, `stage` und `subshop`.
`cmsTemplates.generateSingleReadError`	Bei `seo/urls/reset` war das Dokument nicht lesbar.
`cmsTemplates.generateSingleParseError`	Bei `seo/urls/reset` war das Dokument kein gültiges JSON.
`cmsTemplates.generateSingleNoUrl`	Bei `seo/urls/reset` fehlte `meta.url` im Dokument.
`cmsTemplates.jsonParseError`	Beim Seitenaufruf war das Dokument kein gültiges JSON. Der Shop liefert 404.

Medienbibliothek

Strapi verfügt über eine integrierte Medienbibliothek, die eine zentrale Verwaltung von Medien wie Bildern, PDFs und anderen Dateien ermöglicht. Alle hochgeladenen Bilder und Dateien werden in der Medienbibliothek gespeichert und können von dort aus verwaltet werden. Dies umfasst das Löschen, Ersetzen oder erneute Verwenden von Medien in verschiedenen Teilen des Strapi-Projekts.

Hochladen von Medien

Medien können entweder direkt in die Medienbibliothek hochgeladen oder während der Pflege von Inhalten hinzugefügt werden. Wenn beim Bearbeiten von Inhalten Medien benötigt werden, kann auf die Medienbibliothek zurückgegriffen werden. Hier besteht die Möglichkeit, bereits hochgeladene Dateien auszuwählen oder neue Dateien hinzuzufügen.

Automatische Bildkonvertierung

Strapi verfügt über einen eingebauten Konverter, der die hochgeladenen Bilder automatisch komprimiert, um die Ladezeiten zu verbessern und den Speicherbedarf zu optimieren. Zusätzlich kommt der WEBSALE Bildkonverter zum Einsatz, der Bilder in das SourceFormat und das WebP-Format umwandelt. Diese Formate bieten verbesserte Kompressionsraten und sind für die Web-Nutzung optimiert.

Template-Integration

Der Template-Manager definiert innerhalb des Templates, welches Bild in welchem Format verwendet wird. Neue Bilder und Medienelemente, die zur Medienbibliothek hinzugefügt werden, müssen daher entsprechend den Vorgaben vom Template-Manager im Template platziert und konfiguriert werden. Weitere Informationen für Template-Manager befinden sich hier.

Strapi für Subshops erweitern

Neue Sprache anlegen

Einstellungen → Internationalisierung
“Neue Sprache hinzufügen”
Sprache auswählen.
Anzeigenamen nicht ändern.
Locale-ID notieren / kopieren. Beispielsweise “Französisch (fr)” - fr wäre hier die Locale-ID.
Speichern.

Sprache einem Subshop zuweisen

Content-Manager → Konfiguration
“+ Eintrag hinzufügen” wählen oder einen bestehenden bearbeiten.
Unter “WEBSALE Subshop ID” kann nun eine kommaseparierte Liste an Subshop-IDs eingetragen werden.
Unter “Strapi Locale ID” muss die im vorherigen Schritt kopierte “Locale-ID” eingefügt werden.
Im Anschluss speichern.

Der WEBSALE Strapi Connector beachtet nun automatisch die neue Sprache.
Content, der im Content-Manager für diese Sprache gepflegt wird, wird auf dem Shopserver in die Verzeichnisse für Subshops abgelegt. Jeder Wert (kommasepariert) stellt einen Subshop-Ordner dar.

​Grundlagen von strapi

​Verständnis der Strapi Architektur

​Content-Type Builder & Content-Manager

​Content-Type Builder: Definition von Strukturen und Komponenten

​Content-Manager: Verwaltung von Inhalten

​Zusammenspiel von Content-Manager und Content-Type Builder

​Sammlungen, Einzel-Einträge und Komponenten

​Sammlungen

​Einzel-Einträge

​Content-Typen zum Erstellen neuer Sammlungen & Einzel-Einträge

​Komponenten

​SEO-Meta-Daten für CMS-Seiten (Meta-Info-Plugin)

​Auslieferung von CMS-Seiten in den Shop

​Der SEO-URL-Generator

​Ablage in der Dateigruppe system

​Welche URL gehört zu welcher Datei

​Hinweise zur URL

​Das Seitendokument

​Der SEO-Block in meta

​Entwurf und Veröffentlichung

​Konfiguration

​Wenn eine CMS-Seite nicht erscheint

​Medienbibliothek

​Hochladen von Medien

​Automatische Bildkonvertierung

​Template-Integration

​Strapi für Subshops erweitern

​Neue Sprache anlegen

​Sprache einem Subshop zuweisen

Grundlagen von strapi

Verständnis der Strapi Architektur

Content-Type Builder & Content-Manager

Content-Type Builder: Definition von Strukturen und Komponenten

Content-Manager: Verwaltung von Inhalten

Zusammenspiel von Content-Manager und Content-Type Builder

Sammlungen, Einzel-Einträge und Komponenten

Sammlungen

Einzel-Einträge

Content-Typen zum Erstellen neuer Sammlungen & Einzel-Einträge

Komponenten

SEO-Meta-Daten für CMS-Seiten (Meta-Info-Plugin)

Auslieferung von CMS-Seiten in den Shop

Der SEO-URL-Generator

Ablage in der Dateigruppe `system`

Welche URL gehört zu welcher Datei

Hinweise zur URL

Das Seitendokument

Der SEO-Block in `meta`

Entwurf und Veröffentlichung

Konfiguration

Wenn eine CMS-Seite nicht erscheint

Medienbibliothek

Hochladen von Medien

Automatische Bildkonvertierung

Template-Integration

Strapi für Subshops erweitern

Neue Sprache anlegen

Sprache einem Subshop zuweisen