So migrieren Sie von WordPress zu einem Headless-CMS

Veröffentlicht: 2022-03-10
Kurze Zusammenfassung ↬ In diesem Artikel werden wir uns ansehen, wann es sinnvoll ist, von einem monolithischen Projekt zu einem Headless-Setup zu migrieren und welche Vorteile damit verbunden sind. Neben einer Schritt-für-Schritt-Anleitung zur Migration von WordPress auf Storyblok Headless CMS, den Problemen, die während des Prozesses auftreten und wie man damit umgeht.

WordPress ist der meistgenutzte Website-Builder der Welt; Fast die Hälfte des Webs hat WordPress verwendet, um ihre Website zu erstellen. Es ist sinnvoll, da es Ihnen ermöglicht, schnell Websites zu erstellen, und über ein reichhaltiges Plugin-Ökosystem verfügt, mit dem Sie Ihre Website skalieren können.

Aber die Technologie entwickelt sich weiter, und es gibt immer mehr Optionen, die das Erstellen von Websites erleichtern. Darüber hinaus geben sie uns die Möglichkeit, die Leistung der Website zu verbessern und mehr Kontrolle und Sicherheit über die Anwendung zu haben.

Die anfängliche WordPress-Architektur ist monolithisch , sodass die Benutzeroberfläche und der Datenzugriff auf derselben Plattform kombiniert werden.

Monolithische, reguläre CMS-Architektur
Monolithische, reguläre CMS-Architektur (große Vorschau)

Seit der Einführung der REST-API auf WordPress kann sie kopflos verwendet werden, sodass Entwickler sie als Backend verwenden und das Frontend in einem anderen Projekt verwenden können.

Auf diese entkoppelte Weise werden Modelle und Controller auf der WordPress-Seite gebündelt , die Datenmanipulation und Datenbankinteraktion handhaben. In der Zwischenzeit interagiert das Frontend nur über einen HTTP-Client mit der REST-API.

Das hat aber auch einige Nachteile, man muss WordPress noch konfigurieren und aktualisieren, es sicher machen und ist für die Entwicklung neuer Funktionalitäten auf deren Technologie angewiesen.

Verwandte Lektüre auf SmashingMag

Für diejenigen unter Ihnen, die gerade erst in die Headless-Welt einsteigen, werden diese Artikel Ihnen helfen, die Besonderheiten dahinter zu verstehen und warum alle mit der Migration beginnen.

  • „Headless CMS in 5 effektiven Minuten erklärt“
  • „Überdenken Sie Ihre Content-Strategie für ein Headless CMS“
  • „Wie das Denken in Komponenten Ihre Produktivität steigern kann“
  • Eine kuratierte Liste von Artikeln zu „Headless“ →

Aber warum auf ein Headless CMS migrieren?

Wenn man bedenkt, dass dieser Artikel zeigen wird, wie man von WordPress zu einem Headless CMS migriert, ist WordPress wahrscheinlich Ihr aktuelles Setup.

Ein Headless CMS gibt uns die Freiheit, uns nur auf das Frontend-Projekt zu konzentrieren , die uns vertraute Technologie und die Struktur unserer Daten zu wählen. Am Ende kümmert es sich um das Content-Management und die Content-Bereitstellung, sodass wir uns um den Rendering-Teil kümmern können.

„Ein Headless CMS ist ein System, das die gleichen Funktionen wie ein Content Management System (CMS) und mehr bietet, die alle über eine API bereitgestellt werden.“
Headless CMS-Architektur
Headless CMS-Architektur (große Vorschau)

Diese Art der Einrichtung ist besonders sinnvoll für Unternehmen mit mehreren Standorten , die Kosten senken oder Prozesse vereinfachen möchten. Eine Headless-Architektur ermöglicht es diesen Unternehmen, das Content-Management in einer einzigen Administrationsschnittstelle zu zentralisieren und die APIs bereitzustellen , die von den verschiedenen Webseiten des Unternehmens genutzt werden.

Eine weitere häufige Verwendung einer Headless-Architektur ist die Erstellung eines Front-End-Projekts, das die Unternehmensmarke repräsentiert. Auf diese Weise haben alle Produkte, die das Unternehmen auf den Markt bringt, das gleiche Erscheinungsbild, aber jedes hat seinen eigenen Inhalt, der im selben Administrationsbereich verwaltet wird.

Hinweis : Dieses Beispiel ist leicht auf Konferenz-Websites wie JSWorld Conference und VueJS Amsterdam zu sehen, die, da sie von denselben Erstellern stammen, das Front-End-Projekt dasselbe sind, nur der Inhalt ändert sich.

Anders als bei einem CMS wie WordPress haben Sie in einem Headless CMS ein Administrationspanel, das bereits für Sie konfiguriert und gepflegt und manchmal auch gehostet ist. Um mit der Erstellung von Inhalten zu beginnen, müssen Sie nur ein Konto erstellen, sich anmelden und können unter anderem Ihre Inhalte erstellen, bearbeiten, duplizieren und löschen, Benutzer verwalten, Inhalte übersetzen und mit Veröffentlichungs-Workflows arbeiten.

Ein Headless-CMS erleichtert es den Leuten in Ihrem Team, den Workflow zu verstehen, egal ob es sich um Content-Ersteller oder Vermarkter handelt, was Sie im Hinterkopf behalten sollten, wenn Sie nicht der einzige sind, der die Inhalte bearbeitet.

Visueller Editor eines Headless-CMS
Visueller Editor eines Headless CMS (Große Vorschau)

Es ist erwähnenswert, dass sich einige Headless CMS nicht nur darauf konzentrieren, Ihnen die Dienste anzubieten, die bereits von einem CMS wie WordPress angeboten werden. Es bietet auch Dienste wie Image-CDNs zur spontanen Größenänderung oder Neuformatierung Ihrer Images oder zusätzliche Sicherheit durch S3-Backups.

Diese Einrichtung gibt Ihnen nicht nur Freiheit, Sicherheit und Komfort, sondern verbessert auch die Leistung Ihrer Anwendung ohne Dienste von Drittanbietern. Indem Sie Ihr Front-End-Projekt einfach über einen HTTP-Client verbinden und die Komponenten und Daten abrufen, können Sie loslegen.

Die Vorteile des Going Headless und wann es Sinn macht

Die Architektur von WordPress bietet oft nicht die Möglichkeiten, die wir manchmal brauchen, wenn wir an einer Website arbeiten, insbesondere wenn es um die Optimierung der Leistung geht, einem der wichtigsten Punkte beim Ranking unserer Website in einer Suchmaschine wie Google und besonders jetzt, wo Web Vitals online ist und läuft.

Aber es ist klar, dass, wenn wir eine persönliche Website haben, an der nur wir selbst arbeiten, es nicht notwendig ist, sie auf ein Headless-Setup zu migrieren. Wenn jedoch mehr Personen an diesem Projekt beteiligt sind (nicht nur Entwickler, sondern auch Inhaltsersteller oder Marketingteams), sollten wir die Einführung von Headless CMS in Betracht ziehen.

Wie kann uns ein Headless CMS helfen, die Leistung unserer Website und die Qualität unseres Front-End-Projekts zu verbessern?

  • Indem Sie das Frontend völlig unabhängig von der Plattform entwickeln können, auf der Sie Ihre Inhalte bearbeiten.

    Die Technologie , die Sie wählen, ist Ihre eigene Wahl . Wenn Sie Ihr Projekt auf das neueste Frontend-Framework aktualisieren wollten, wären Sie nicht auf ein Backend angewiesen und könnten dies tun, ohne Migrationen überdenken zu müssen.

  • So können Sie Multiplattform- Projekte erstellen, ohne von verschiedenen Administrationspanels abhängig zu sein.

    Wenn Sie am Ende für eine App eine kürzere Beschreibung als die Hauptwebsite benötigen, können Sie immer ein neues Feld „short_description“ verwenden und es einfach im Frontend dieser bestimmten App darstellen.

  • Es soll die Entwicklung erleichtern und den Prozess der Erstellung einer Website sowie deren Skalierung vereinfachen.

    Indem wir das Front-End vollständig isoliert haben, können wir das visuelle Erscheinungsbild unserer gesamten Anwendung ändern , ohne die Struktur unserer Inhalte zu ändern.

  • Wir bieten immer Dienstleistungen an, die es uns ermöglichen, unsere Vermögenswerte und die Reaktionsgeschwindigkeit , mit der sie uns zur Verfügung gestellt werden, zu optimieren . Letztendlich werden alle unsere Daten über CDN-Netzwerke geliefert.

Ein Content Delivery Network (CDN) ist ein geografisch verteiltes Netzwerk aus Proxy-Servern und ihren Rechenzentren. Das Ziel besteht darin, eine hohe Verfügbarkeit und Leistung bereitzustellen, indem der Dienst räumlich relativ zu den Endbenutzern verteilt wird.

Was ist, wenn wir uns Sorgen darüber machen, wie es mit der Struktur unserer Marke oder unseres Unternehmens funktionieren wird?

  • Neben der Unterstützung plattformübergreifender Anwendungen ermöglicht es uns auch, die Markenkonsistenz zu wahren .

    Das Front-End als Basisprojekt und mehrere Bereiche in einem Headless CMS zu haben, ermöglicht Ihnen eine Konsistenz zwischen Ihren Produkten und erleichtert die Skalierbarkeit, da wir weniger Code zu warten haben.

  • Obwohl nicht alle Headless-CMS diesen Vorteil haben, verfügt das Headless-CMS, zu dem wir migrieren, Storyblok, über einen visuellen Editor, der die Schaffung von Unabhängigkeit zwischen Teams ermöglicht. Die Redakteure oder Inhaltsersteller können auf das Panel zugreifen, um vorhandene Inhalte zu bearbeiten oder neue Inhalte zu erstellen, und können eine Vorschau sehen, wie sie vor der Veröffentlichung aussehen werden. So müssen sie das Entwicklungsteam nicht in diesen Prozess einbeziehen und können ihre Arbeit effizienter erledigen.

  • Es rationalisiert auch das Content-Management, indem es Ihnen ermöglicht, Ihren eigenen Content-Workflow einzurichten. Sie können die Phasen definieren, die ein Inhalt durchlaufen muss, bevor er veröffentlicht wird, und nur wenn er den Prozess erfolgreich durchlaufen hat, wird er veröffentlicht.

Wie kann ein Headless CMS im Vergleich zu einem herkömmlichen CMS Zeit sparen?

  • Sich um die Aufrechterhaltung der Sicherheit der Plattform kümmern und sie in Ihrem Namen aktualisieren. Wann immer es einen Fehler gibt oder Benutzer eine neue Funktion benötigen, wird das Team hinter Ihrem Headless CMS es für Sie entwickeln, Sie müssen es nur noch verwenden!
  • Ständige Verbesserung der Benutzererfahrung (UX) und des Designs (UI) für Sie, damit Inhaltsersteller und Entwickler sich beim Erstellen neuer Felder, Komponenten oder Seiten wohlfühlen. Aber nicht nur auf den visuellen Aspekt, sondern sie werden auch versuchen, die Leistung der Datenbank zu verbessern, damit Sie Ihre Inhalte sofort erhalten und die ganze damit verbundene Arbeit vergessen.

Monolithisch vs. kopflos

Feature Monolithisch Kopflos
Die Architektur Gekoppelt: verknüpftes Back-End-Front-End Entkoppelt: unabhängiges Frontend-Projekt
Technologie Sie müssen diejenige verwenden, in der das Projekt entwickelt wird Freiheit bei der Wahl Ihrer Front-End-Technologie
Plattformübergreifend Beschränkt auf jeweils ein Front-End Verbindet sich mit beliebigen Front-End-Projekten
Content-Workflow Restriktiv Brauch
Sicherheit und Updates Sie kümmern sich Es kümmert sich um Sie

Nachdem ich die Vorteile gesehen habe, die ein Headless-Setup für unser Projekt und die Leute, die daran arbeiten, bringen kann, denke ich, dass es an der Zeit ist, einen Blick auf die Schritte zu werfen, die wir zur Migration unseres Projekts benötigen.

Was Sie beachten müssen, wenn Sie kopflos werden

Wie wir bereits erwähnt haben, ermöglichen Headless CMS eine saubere Trennung der Anliegen zwischen Inhaltserstellern und Entwicklern. Auf diese Weise (in einem Headless CMS) konzentriert sich der Entwickler auf die Erstellung der Inhaltsstruktur, die im Frontend-Projekt dargestellt wird, und der Redakteur ist dafür verantwortlich, die Komponenten zu verwenden und sie im Admin-Panel mit Inhalten zu füllen .

Art der Inhalte, die wir in einem Headless CMS erstellen können

1. Arten von Einträgen oder Vorlagen

Ähnlich wie benutzerdefinierte Beitragstypen in WordPress, aber mit mehr Freiheit und Erweiterbarkeit, wenn es um Datentypen und Editoren geht.

Wenn Sie einen neuen Inhaltseintrag in Ihrem Dashboard erstellen, erwarten Sie, dass Sie je nach Situation auswählen können, welcher Typ es ist. Wenn Sie beispielsweise eine Website mit einem Blog haben, sollten Sie mehrere Arten von Vorlagen haben, eine für Seiten mit Auflistungen oder dynamischen Inhalten namens „ Seite “ und eine für jeden Blogeintrag „ Beitrag “.

Je nachdem, welches Headless-CMS Sie gewählt haben, variiert der Name, aber das Konzept ist dasselbe. In Storyblok werden diese Arten von Entitäten als Content Type bezeichnet. „Inhaltstypen“ definieren die Art des Inhaltseintrags und können die grundlegenden Felder für Ihre Inhaltseinträge enthalten. Standardmäßig haben wir einen Inhaltstyp „Seite“.

2. Wiederverwendbare Komponenten

In einem Headless CMS können Sie zusätzlich zu Inhaltstypen verschachtelte Komponenten erstellen und diese zwischen Inhaltstypen und anderen Komponenten wiederverwenden. In Storyblok heißt diese Art von Komponente – wie Sie vielleicht anhand ihres Namens bemerkt haben – Blok .

Um sie in einem Inhaltstyp wie einer Seite zu verwenden, müssen Sie ein Feld im Schema der Typblöcke erstellen. Mit diesem Feld können Sie Ihrer Seite verschachtelte Komponenten hinzufügen, während Sie Inhalt hinzufügen.

Aber im Prinzip werden wir solche Komponenten während der Migration nicht brauchen. Es gibt Ihnen einfach die Flexibilität , robuste und dynamische Anwendungen zu erstellen, ohne den Entwickler einbeziehen zu müssen.

Wenn beispielsweise ein Mitglied des Marketingteams der Seite „Über uns“ einen neuen Hero hinzufügen möchte, wenn die Hero-Komponente verschachtelt erstellt wurde und die Seite ein Feld „Blocks“ hatte, könnte die Marketingperson den Hero hinzufügen, ohne das einbeziehen zu müssen Entwickler.

Rendern der Daten aus dem Headless CMS

Während wir die Struktur unserer Inhalte im Headless CMS-Panel definieren, müssen wir uns überlegen, mit welchem ​​Framework wir unser Frontend-Projekt erstellen und welchen HTTP-Client wir verwenden werden.

Bei der Auswahl eines Rahmens müssen wir mehrere Faktoren berücksichtigen:

Sind mein Team und ich mit dieser Technologie vertraut?

Kann ich meine Inhalte so rendern, wie es für mein Projekt erforderlich ist?

Verfügt es über Plugins oder Module, die die Integration mit dem von mir verwendeten Headless CMS erleichtern?

In den meisten Fällen wird ein statischer Standort ausreichen und immer die wirtschaftlichste und performanteste Lösung sein. Sie müssen also nur nach einem Static-Site-Generator für die Technologie suchen, mit der Sie vertraut sind, z. B. Nuxt für Vue oder Next für die React-Bibliothek.

Durch die Verbindung dieser beiden Dinge werden ein Headless CMS und ein Static Site Builder als eine Reihe von Best Practices für die Webentwicklung betrachtet, die sich darauf konzentrieren, die höchste Leistung, Sicherheit und die niedrigsten Kosten zu bieten. Diese Architektur wird auch als Jamstack bezeichnet. Es handelt sich um eine Architektur, die darauf ausgelegt ist, das Web schneller, sicherer und einfacher zu skalieren. Es baut auf vielen der Tools und Workflows auf, die Entwickler lieben und die maximale Produktivität bringen.

Wenn Sie die trendigen Frameworks verwenden, erhalten Sie sicher einen Integrationsleitfaden mit dem Headless CMS, mit dem Sie arbeiten werden, und die meisten von ihnen haben bereits ein Modul oder Paket, mit dem Sie Informationen von der API und in vielen Fällen erhalten können erweitere es.

Sie müssen nur noch die Struktur Ihrer Komponenten definieren , wie Sie die Daten in Ihrem Headless CMS strukturiert haben, und den Content-Publishing-Prozess automatisieren. Wenn Sie beispielsweise die Webhooks verwenden, die Ihnen das Headless CMS zur Verfügung stellt, können Sie einen Build-Prozess in Ihrem bevorzugten Hosting durch dessen Build-Hooks starten, sobald der Inhalt veröffentlicht wurde.

Zeitaufwand, den Sie benötigen

Wie bei jeder Migration hängt der Zeitaufwand immer proportional von der Komplexität Ihres Projekts ab. Wenn wir über eine gemeinsame WordPress-Site sprechen, müssen Sie nur die Post-Typen migrieren, die Sie definiert haben oder die standardmäßig darin enthalten sind, wie Seiten, Posts und Kategorien, und deren Inhalt.

Wenn Sie Ihr Projekt hingegen mit mehreren Plugins angepasst haben, müssen Sie diese über das Frontend-Projekt entwickeln oder die von Ihrem Headless CMS bereitgestellten verwenden. Wenn wir beispielsweise SEO-bewusst sind und daher Yoast SEO auf WordPress verwenden, haben wir das Field-Type SEO-Plugin in Storyblok, um uns beim Übergang zu helfen, aber wir müssen unsere Sitemap im Frontend noch entwickeln mit einem Führer, der uns hilft.

Am Ende wird die gesamte Last der Entwicklung auf das Frontend-Projekt fallen, da die Einrichtung des Headless CMS nicht so viel Zeit in Anspruch nehmen wird.

Aber lass uns aufhören zu reden und lass uns einen Blick darauf werfen!

Schritte zum Migrieren unserer Inhalte von WordPress zu Storyblok

Die Migration wird aus vier Schritten bestehen, von der Erstellung eines Spaces in unserem neuen Headless CMS Storyblok bis hin zur Darstellung der migrierten Inhalte in unserem Frontend-Projekt, auf das wir weiter unten im Detail eingehen werden und in dem ich Ihnen Ressourcen überlasse erleichtern Ihnen die Migration.

Lass uns anfangen!

1. Einen Raum in Storyblok erstellen

Um einen Bereich in Storyblok zu erstellen, benötigen Sie zunächst ein Konto. Dazu müssen Sie den Plan auswählen, der am besten zu Ihnen passt.

Gehen Sie zur Preisseite und beginnen Sie mit dem Plan, der Ihren Anforderungen am besten entspricht, oder probieren Sie den kostenlosen Plan zum Testen aus.

Erstellen Sie Ihr Konto und Sie können auf das Panel zugreifen.

Erstellen Sie ein Kontoformular in Storyblok
Erstellen Sie ein Kontoformular in Storyblok (große Vorschau)

Wählen Sie „Neuen Bereich erstellen“ und legen Sie los!

Einen neuen Raum in Storyblok erstellen
Erstellen eines neuen Raums in Storyblok (große Vorschau)

Space ist ein Content-Repository. Betrachten Sie es als einen Ort, an dem alle Inhalte zu einem Projekt aufbewahrt werden. Jeder Bereich hat seine eigenen Komponenten, Datenquellen, Assets, Umgebungen, Domänen, Mitarbeiter und Berechtigungen.

Nehmen Sie sich etwas Zeit, um die Abschnitte in der linken Seitenleiste zu erkunden. Beginnen Sie, indem Sie Folgendes durchsuchen:

  • Inhalt , dies ist der Ordner, in dem die Inhalte gespeichert werden, in denen das Marketingteam die meiste Zeit verbringen wird.
  • Assets , in denen alle Bilder gespeichert werden, die Sie dann über den CDN-Dienst erhalten können, optimiert und in beliebiger Größe.
  • Komponenten , wo Sie die Inhaltstypen und verschachtelten Komponenten erstellen .
  • Einstellungen , der Abschnitt, in dem Sie die Daten Ihres Bereichs sowie die Sprachen Ihrer Anwendung, die Arbeitsabläufe, denen Ihre Inhalte vor der Veröffentlichung folgen sollen, Benutzerberechtigungen usw. konfigurieren können. Nehmen wir an, dieser Bereich ist der eine, die sich auf das IT-Team des Projekts bezieht.
Komponentenbereich im Storyblok-Bereich
Komponentenbereich im Storyblok-Bereich (große Vorschau)

Wenn Sie dennoch alle Optionen auf dem Dashboard erkunden möchten, bevor Sie in die Migration einsteigen, empfehle ich Ihnen, einen Blick auf die Benutzeroberfläche von Storyblok zu werfen.

Nachdem Sie nun ein wenig über das Storyblok-Ökosystem Bescheid wissen, ist es an der Zeit zu definieren, wie der Inhalt unserer Anwendung aussehen wird.

2. Modelle definieren

Um WordPress-Inhalte zu Storyblok zu migrieren, besteht der nächste Schritt darin, die Schemata zu erstellen, die die WP-Datenstruktur definieren, indem Beitragstypen im Storyblok-Bereich erstellt werden.

Beginnen wir mit Seiten und Beiträgen (den wichtigsten Beitragstypen auf jeder WP-Site), die wir page und post in Storyblok nennen.

Das Schema der Seiten in WP enthält die Felder: Titel , Slug , Beitragsbild , Datum und Inhalt .

Hinweis : Um alle Felder zu sehen, die in einem Beitragstyp enthalten sind, gehen Sie zum Schema unter WP-REST-API-Schemareferenzen.

Was Sie wissen müssen, ist, dass standardmäßig für jeden Inhaltstyp in Storyblok einige Felder bereits für Sie definiert sind, wie z. B. Name , Slug , Tags , Erstveröffentlichungsdatum und so weiter.

Standardfelder für Inhaltstyp in Storyblok
Standardfelder für Inhaltstyp in Storyblok (große Vorschau)

Diese Felder könnten verwendet werden, um den Inhalt von WP zu migrieren. Sie müssen es nur erweitern, indem Sie dem Seiteninhaltstyp „featured_image“ und „ content “ hinzufügen.

Gehen Sie in Ihrem Bereich zum Abschnitt „ Komponenten “, klicken Sie auf die standardmäßig erstellte page , entfernen Sie das Textfeld und fügen Sie „featured_image“ als Typ „ Assets > Images und „ Inhalte als Rich-text “ hinzu.

Inhaltstyp Seitenfelddefinition im Abschnitt Storyblok-Komponenten.
Inhaltstyp Seitenfelddefinition im Abschnitt Storyblok-Komponenten. (Große Vorschau)

Sobald das page fertig ist, fahren wir mit dem post fort. Für den Inhaltstyp des Beitrags müssen weitere Informationen angegeben werden, z. B. feature_image , excerpt , content und Beziehungen zu anderen Typen wie Authors oder Categories .

Inhaltstyp Post-Felddefinition im Abschnitt Storyblok-Komponenten
Definition der Inhaltstyp-Postfelder im Abschnitt „Storyblok-Komponenten“ (große Vorschau)

Da Autoren und Kategorien auch ihren eigenen Inhalt haben, gehen Sie zum Inhaltsbereich in der Seitenleiste und erstellen Sie ein paar Ordner mit den Namen authors und categorys .

Jedem der Ordner muss ein Standard-Inhaltstyp zugeordnet sein. Erstellen Sie dazu im Abschnitt „ KomponentenAutor und Kategorie als neue Inhaltstypen und ordnen Sie dann den Inhaltstyp relativ zu jedem Ordner zu, indem Sie auf die drei Punkte rechts neben dem Ordner klicken und Einstellungen auswählen.

Standardmäßiges Auswählen eines Inhaltstyps für den Ordner „Kategorien“ im Bereich „Storyblok“.
Standardmäßiges Auswählen eines Inhaltstyps für den Ordner „Kategorien“ im Bereich „Storyblok“. (Große Vorschau)

Auf diese Weise können Sie im Post-Content-Typ ein Single-Option- oder Multi-Options- Feld mit Quell- Storys hinzufügen und auf den Ordner verweisen, der für jedes Feld erstellt wurde:

  • Autoren
    Dies gibt den Ordner an, in dem sie sich befinden authors/ .
  • Kategorien
    Dies gibt den Ordner an, in dem sie sich befinden categories/ .
Feld „Kategorien mit mehreren Optionen“ für den Inhaltstyp „Beitrag“.
Kategorienfeld mit mehreren Optionen für den Inhaltstyp Post (große Vorschau)

Hinweis : Wenn Sie mehr über diese Beziehung erfahren möchten, werfen Sie einen Blick auf den Artikel Beziehung zwischen Autoren und Artikeln.

Nachdem Sie nun gesehen haben, wie Sie einige Inhaltstypen und Beziehungen zwischen ihnen erstellen, müssen Sie die restlichen Modelle mit denselben Schritten definieren.

Hinzufügen eines Inhaltstyps: Global

Und Sie fragen sich, was ist mit den Inhalten, die alle meine Seiten teilen? Wie das Navigationsmenü, die Fußzeile und andere gemeinsame Elemente?

Keine Sorge, Storyblok hat sich darüber bereits Gedanken gemacht und bietet uns eine einfache Anleitung, um unsere globalen Elemente dynamisch zu definieren. Es zeigt uns, wie man einen globalen Inhaltstyp erstellt und wie man ihn im Inhaltsbereich verwendet.

3. Migrieren des Inhalts

Jetzt ist es an der Zeit, mit der Migration der von Ihnen gespeicherten Inhalte zu beginnen. Um auf WP-Inhalte zuzugreifen, müssen Sie auf die REST-JSON-API zugreifen. Greifen Sie auf den Pfad /wp-json zu, wenn das Projekt bereitgestellt wird, oder ?rest_route=/ , wenn es lokal ist.

Falls keiner der beiden Wege funktioniert, überprüfen Sie den HTML-Code Ihrer Seite auf einen Link im Kopf mit rel="https://api.w.org/" , wie im WP-Erkennungsleitfaden angegeben, und erhalten Sie den richtigen .

 <link rel="https://api.w.org/" href="https://localhost/your-site/index.php?rest_route=/">

Um uns bei der Migration zu helfen, haben uns die Storyblok-Entwickler ein Plugin zur Verfügung gestellt, das uns viel Arbeit ersparen wird. Dieses Plugin heißt WordPress-Importer, darauf ist es möglich, den entsprechenden Inhaltstyp in Storyblok für den zu migrierenden WP-Post-Typ zu definieren, und es wird ihn in unseren Bereich verschieben und die Bilder für uns in unseren Assets -Bereich migrieren.

Hinweis : Die Verwendung dieses Skripts erfordert Knoten ≥14.0.0, da es optionale Verkettung verwendet.

Erstellen des Migrationsskripts

Als erstes müssen Sie das Repository klonen. Installieren Sie dann die NPM-Pakete mit npm install oder yarn und erstellen Sie im Stammverzeichnis des Projekts eine Datei mit dem Namen „ migrateWPtoStoryblok.js“ . Um das Skript auszuführen, benötigen Sie ein Skript in package.json, um es auszuführen, fügen Sie hinzu:

 "migrate": "node ./migrateWPtoStoryblok.js"

Sobald alles fertig ist, ist es an der Zeit, das Skript gemäß den README-Spezifikationen zu definieren. Und wie Sie sehen können, müssen Sie als Nächstes die Space_id und das OAuth -Token finden, um eine Verbindung zum Storyblok-Bereich herzustellen.

  • Die Space_id befindet sich im Abschnitt Einstellungen der Seitenleiste, sobald Sie darauf klicken, sehen Sie sie auf der rechten Seite.
  • Um das OAuth -Token zu generieren, müssen Sie zum oberen Rand der Seitenleiste gehen, auf den kleinen Pfeil direkt neben dem Storyblok-Logo klicken und zu Mein Konto gehen. Wenn wir nach unten scrollen, sehen wir den Abschnitt Persönliche Zugriffstoken , generieren einen und kopieren ihn.

Wenn Sie beide Geheimnisse erhalten haben, können Sie sie zusammen mit der URL der JSON-API Ihres Projekts am Anfang des Skripts hinzufügen:

 import { Wp2Storyblok } from './index.js' const wp2storyblok = new Wp2Storyblok('https://your-domain.com/wp-json', { token: 'storyblok-oauth-token', // My Account > Personal access tokens space_id: 'space-id', // Settings })

Wie in den vorherigen Abschnitten beschrieben, ist der Seiteninhaltstyp in Storyblok das Äquivalent zum Beitragstyp in WP- Seiten . Im Codeblock unten sehen Sie, wo Sie die einzelnen angeben müssen.

Und sobald der Beitragstyp und der Inhaltstyp definiert sind, ist es an der Zeit, den Namen der Felder, die in diesem Entitätstyp in WP verwendet werden, und den entsprechenden Namen in Storyblok in der Option schema_mapping .

 import { Wp2Storyblok } from './index.js' const wp2storyblok = new Wp2Storyblok('https://your-domain.com/wp-json', { // ... Secrets content_types: [ { name: 'pages', // Post type in WP new_content_type: 'page', // Equivalent Content type in Storyblok folder: '', // OPTIONAL: To save all the content of the same type in a specific folder schema_mapping: { "title": "name", // "Field in WP": "Field in Storyblok" } } ] })

Hinweis : Damit die Migration korrekt funktioniert, stellen Sie sicher, dass die Permalinks nach dem Namen des Eintrags ausgewählt werden und nicht so einfach. Andernfalls erstellt das Skript keine Eltern-Kind-Beziehung zwischen Seiten.

Innerhalb von schema_mapping können Sie verschiedene Arten von Feldern definieren, diese können sein:

  • Ein einfaches Feld wie title .
  • Eine Untereigenschaft eines Felds, wie in diesem Fall die URL des Feature-Bildes.
    Hinweis : Das Plugin selbst kümmert sich um die Migration der Bilder in den Storyblok-Bereich über die zugehörige URL in links.wp:featuredmedia.0 .
  • Ein Feld, das in einen verschachtelten Block in Storyblok migriert wurde.

    Stellen Sie sich vor, Sie möchten eine Komponente in Storyblok erstellen, um den Rich-Text Ihrer Website so zu definieren, dass alle Beitragstypen, die ihn verwenden, den gleichen Stil und die gleichen Optionen haben.

    Dazu können Sie das Objektformat verwenden und den Namen des Felds im Storyblok-Modell unter der Feldeigenschaft , den Namen der Komponente , die Sie in diesem Feld speichern möchten, und den Namen des Felds in der Komponente, in der sich der Inhalt befindet, angeben wird migriert.

 import { Wp2Storyblok } from './index.js' const wp2storyblok = new Wp2Storyblok('https://your-domain.com/wp-json', { // ... Secrets content_types: [ { // ... Post type WP:Storyblok schema_mapping: { "title": "name", // "Field in WP": "Field in Storyblok" "_links.wp:featuredmedia.0": "content.preview_image", // Using the dot notation you can define subproperties. // Using nested blocks in Storyblok "content": { field: 'content.body_items', // Field name in Storyblok component: "rich-text", // Component name inside the above field component_field: "content" // Field name inside the component where you want to migrate the content } } } ] }) wp2storyblok.migrate()

Seite Eintragstyp

Nachdem Sie nun wissen, wie die Feldtypen definiert werden, würde es für das Seitenschema wie im folgenden Codeblock aussehen.

Das Plugin kümmert sich um die Eltern-Kind-Beziehung zwischen Seiten, indem es einen Ordner in Storyblok unter dem Slug des Elternteils erstellt und das Elternteil als Heimat dieses Ordners zuordnet.

Wenn das Inhaltsfeld außerdem Bilder enthält, migriert das Plugin diese auch für Sie!

 { name: 'pages', // Name of the post type in WP new_content_type: 'page', // Name of the Content Type in Storyblok schema_mapping: { "date": "first_published_at", "title": "name", "slug": "slug", "_links.wp:featuredmedia.0": "content.featured_image", "content": "content.content", } }

Eintragstyp Beitrag

Beiträge haben ein ähnliches Schema wie Seiten, aber um sie in diesem Fall in einem Ordner zu speichern, müssen Sie den Namen des Ordners unter dem Eintragstyp definieren:

 { name: 'posts', // Post type name in WP new_content_type: 'post', // Content Type name in Storyblok folder: 'articles', // Destination folder name in Storyblok schema_mapping: { "date": "first_published_at", "title": "name", "slug": "slug", "_links.wp:featuredmedia.0": "content.featured_image", "excerpt": "content.excerpt", "content": "content.content", } }

Eintragstyp-Kategorie

Und nachdem das Schema für Beiträge definiert wurde, ist es sinnvoll, das Schema für die Kategorien zu definieren, damit sie wie im vorherigen Abschnitt beschrieben verknüpft werden können.

Um den Ordner , der sie enthält, als Kategorien und nicht als Kategorie, ihren Standardnamen, zu definieren, müssen Sie zur Option „ Permalinks “ im WordPress-Adminbereich gehen und die Basisoption „Kategorien“ in „ categories “ ändern. Dann ist das Multioptionsfeld der Post-Einträge dasjenige, das die Beziehung zu den entsprechenden Kategorien hat.

Hinweis : Diese Schritte sind die gleichen wie beim Migrieren von Autoren und Verknüpfen mit Artikeln.

 { name: 'categories', // Name of the post type in WP new_content_type: 'category', // Name of the Content Type in Storyblok // By default will be contained by a folder called Category (change it in the Permalinks option in WP) schema_mapping: { "name": "name", "slug": "slug", "description": "content.description", "parent": "content.parent", } }

Vollständiges Endskript

Der folgende Code ist das resultierende Migrationsskript aus einem WP-Projekt mit den Grundtypen in den von uns erstellten Storyblok-Bereich.

 import { Wp2Storyblok } from './index.js' const wp2storyblok = new Wp2Storyblok('https://your-domain.com/wp-json', { token: '', space_id: 34234, content_types: [ { name: 'pages', // Name of the post type in WP new_content_type: 'page', // Name of the Content Type in Storyblok schema_mapping: { "date": "first_published_at", "title": "name", "slug": "slug", "_links.wp:featuredmedia.0": "content.featured_image", "content": "content.content", } }, { name: 'categories', // Name of the post type in WP new_content_type: 'category', // Name of the Content Type in Storyblok // By default will be contained by a folder called Category (change it in the Permalinks option in WP) schema_mapping: { "name": "name", "slug": "slug", "description": "content.description", "parent": "content.parent", } }, // Add authors as categories. { name: 'posts', // Name of the post type in WP new_content_type: 'post', // Name of the Content Type in Storyblok folder: 'articles', // Name of the destination folder in Storyblok schema_mapping: { "date": "first_published_at", "title": "name", "slug": "slug", "_links.wp:featuredmedia.0": "content.featured_image", "excerpt": "content.excerpt", "content": "content.content", } } // More schemas... ] }) wp2storyblok.migrate()

4. Erstellen Sie ein Front-End-Projekt

Nachdem der Inhalt bereits im Storyblok-Dashboard gespeichert ist, ist es an der Zeit, das Front-End-Projekt mit Storyblok zu verbinden.

Unabhängig von Ihrem Framework oder Ihrer JS-Bibliothek bietet Storyblok den JavaScript-Client, der Ihnen bei der Integration hilft. Falls Sie ein bestimmtes Framework verwenden, finden Sie außerdem andere Pakete, die Ihnen den Weg erleichtern, wie in Nuxt das Modul storyblok-nuxt .

Diese JavaScript-API enthält auch eine Brücke zwischen Storyblok und Ihrer Front-End-Anwendung. Die Brücke ist für die Kommunikation über Iframe mit Storyblok verantwortlich, um der Bearbeitungsschnittstelle mitzuteilen, welche Komponente geöffnet werden soll, wenn der Benutzer darauf klickt.

Hier ist eine Liste von Tutorials, die Sie auf Storyblok finden können, um Ihr Front-End-Projekt zu verbinden.

Hinweis : Wenn Sie Ihre Technologie nicht darunter finden, machen Sie sich keine Sorgen, es gibt viele andere Tutorials auf der Storyblok-Website, suchen Sie in der Suchmaschine nach Ihrer, und wenn Sie keine finden, empfehle ich Ihnen, sie zu kontaktieren. und Sie werden noch viel mehr Menschen helfen!

  • Nächste
  • Gatsby
  • Sehen
  • Weiter
  • Eckig
  • Schlank
  • Glut
  • AMPERE

5. Hosten Sie Ihr Front-End-Projekt und automatisieren Sie die Bereitstellung

Sobald Ihr Projekt bereit ist, in Produktion zu gehen, wählen Sie einen Hosting-Anbieter aus und verknüpfen Ihr Repository für eine einfache Bereitstellung. Dann fragen Sie sich:

Wie stelle ich meine statische Website erneut bereit, wenn ich einen Eintrag auf Storyblok veröffentliche?

Die Antwort ist ganz einfach: indem Sie die von Storyblok angebotenen Webhooks und die Build-Hooks Ihres Hostings verwenden.

Um Ihnen ein echtes Beispiel zu geben, können Sie Build-Hooks-URLs in Netlify im Bereitstellungsabschnitt erstellen; Die für Storyblok in den Build-Hooks erstellte URL wird in das Feld EinstellungenWebhooksStory veröffentlicht und unveröffentlicht im Storyblok-Bereich verschoben.

Storyblok-Webhooks-Feld
Storyblok-Webhooks-Feld (große Vorschau)

Leitfäden und Tools, die wir während der Migration verwendet haben

Lassen Sie uns die Links zusammenfassen, die bei der Migration des Inhalts geholfen haben, und diejenigen, die dazu beigetragen haben, die Funktionsweise der REST-API und des Headless-CMS zu verstehen, zu dem Sie migrieren.

WP-REST-API-Dokumentation erforderlich

REST-API

  • REST-API-Endpunktreferenz für Entwickler
  • Verwenden der REST-API
  • Entdecken der API und ihrer Route

Schemata

  • Verweis auf das Seitenschema
  • Schemareferenz posten
  • Schemareferenz für Kategorien

Migration zu Storyblok

Allgemeine Information

  • Die offizielle Storyblok-Website
  • Storyblok-Preise und -Pläne

Dokumentation

  • Verständnis der Benutzeroberfläche
  • Inhaltliche Strukturen
  • Einrichten der Blog-Inhaltsstruktur in Storyblok

Globale Komponenten

  • So erstellen Sie mit Storyblok eine Website-Header-Menünavigation
  • Die Storyblok-Brücke V2

SEO-bezogen

  • Wie erstelle ich eine 445r-Sitemap mit einem Headless-CMS?
  • https://www.storyblok.com/apps/seo

Webhooks und Build-Hooks

  • Alles über Webhooks
  • So verwenden Sie Storyblok-Webhooks
  • Hosting-Build-Hooks – Netlify-Beispiel

Skripte und Pakete

  • Universelles JavaScript-SDK für die API von Storyblok: https://github.com/storyblok/storyblok-js-client
  • Hilfsprogramm für die Migration von WP zu Storyblok: https://github.com/storyblok/wordpress-importer

Jamstack

  • Die Jamstack-Website
  • Eine Liste statischer Site-Generatoren für Jamstack-Sites

Fazit

Nachdem Sie diesen Artikel gelesen haben, wissen Sie, warum ein Headless-Setup Ihr ​​Projekt verbessert, wie Sie von Ihrem WordPress-Projekt zu einem Headless-CMS wie Storyblok migrieren und wie Sie Ihr Projekt weiter verbessern und erweitern können.

Wie Sie gesehen haben, sind die Möglichkeiten eines Headless-Setups endlos . After the migration, you will have enormous flexibility to scale your project, improve its performance and SEO, increase the productivity of the development team and stay on top of the latest trends.

Everyone is starting to migrate and there is more and more content and scripts that make it easier. What are you waiting for to migrate your WordPress?