Comment migrer de WordPress vers un CMS sans tête

Cet article a été aimablement soutenu par nos chers amis de Storyblok, un CMS sans tête convivial avec un éditeur visuel, des composants imbriqués et des blocs de contenu personnalisables pour les sites Web et les applications. Merci!

WordPress est le constructeur de sites Web le plus utilisé au monde. près de la moitié des internautes ont utilisé WordPress pour créer leur site Web. Cela a du sens, car il vous permet de créer rapidement des sites Web et dispose d'un riche écosystème de plugins pour vous aider à faire évoluer votre site.

Mais la technologie évolue et il existe de plus en plus d'options qui facilitent la création de sites Web. De plus, ils nous donnent la possibilité d'améliorer les performances du site et d'avoir plus de contrôle et de sécurité sur l'application.

L' architecture initiale de WordPress est monolithique , de sorte que l'interface utilisateur et l'accès aux données sont combinés sur la même plate-forme.

Depuis l'introduction de l'API REST sur WordPress, elle peut être utilisée de manière sans tête, permettant aux développeurs de l'utiliser comme backend et d'avoir le front-end dans un projet différent.

De cette manière découplée, les modèles et les contrôleurs sont regroupés du côté de WordPress , gérant la manipulation des données et l'interaction avec la base de données. Pendant ce temps, le frontal interagit uniquement avec l'API REST via un client HTTP.

Mais cela a aussi quelques inconvénients, vous devez toujours configurer et mettre à jour WordPress, le sécuriser et êtes dépendant de leur technologie pour le développement de nouvelles fonctionnalités.

Lecture connexe sur SmashingMag

Pour ceux d'entre vous qui débutent dans le monde sans tête, ces articles vous aideront à comprendre les tenants et les aboutissants et pourquoi tout le monde commence à migrer.

• « Headless CMS expliqué en 5 minutes efficaces »
• "Repensez votre stratégie de contenu pour un CMS sans tête"
• "Comment penser en composants peut augmenter votre productivité"
• Une liste organisée d'articles liés à "Headless" →

Mais pourquoi migrer vers un CMS sans tête ?

Tenant compte du fait que cet article montrera comment migrer de WordPress vers un CMS Headless, WordPress est probablement votre configuration actuelle.

Un Headless CMS nous donnera la liberté de nous concentrer uniquement sur le projet front-end , de pouvoir choisir la technologie que nous connaissons et sur la structure de nos données. Au final, il s'occupe de la gestion du contenu et de la livraison du contenu, pour que nous puissions nous occuper de la partie rendu.

"Un Headless CMS est un système qui fournit les mêmes fonctionnalités qu'un système de gestion de contenu (CMS) et plus encore, le tout exposé via une API."

Ce type de configuration est particulièrement utile pour les entreprises qui ont plusieurs sites et qui souhaitent réduire les coûts ou simplifier les processus. Une architecture headless permet à ces entreprises de centraliser la gestion de contenu dans une interface d'administration unique , fournissant les API qui seront consommées par les différentes pages web de l'entreprise.

Une autre utilisation courante d'une architecture sans tête consiste à créer un projet frontal qui représente la marque de l'entreprise. De cette façon, tous les produits lancés par l'entreprise auront la même apparence, mais chacun aura son propre contenu, géré dans le même panneau d'administration.

Note : Cet exemple est facilement visible sur les sites de conférence tels que JSWorld Conference et VueJS Amsterdam qui, étant issus des mêmes créateurs, le projet front-end est le même, seul le contenu change.

Contrairement à un CMS comme WordPress, dans un CMS sans tête, vous avez un panneau d'administration déjà configuré et maintenu , et parfois également hébergé, pour vous. Pour commencer à créer du contenu, il vous suffit de créer un compte, de vous connecter et vous pourrez créer, modifier, dupliquer et supprimer votre contenu, gérer les utilisateurs, traduire le contenu et travailler avec les workflows de publication, entre autres.

Un CMS sans tête permettra aux membres de votre équipe de comprendre plus facilement le flux de travail, qu'ils soient créateurs de contenu ou spécialistes du marketing, ce qu'il faut garder à l'esprit si vous n'êtes pas le seul à modifier le contenu.

Il est à noter que certains CMS Headless, ne se concentrent pas uniquement sur vous offrir les services déjà proposés par un CMS comme WordPress. Il fournit également des services tels que des CDN d'images pour redimensionner ou reformater vos images à la volée, ou une sécurité supplémentaire via des sauvegardes S3.

Cette configuration vous apportera non seulement liberté, sécurité et confort, mais améliorera également les performances de votre application sans services tiers. En connectant simplement votre projet frontal via un client HTTP et en obtenant les composants et les données, vous serez opérationnel.

Les avantages d'aller sans tête et quand cela a du sens

L'architecture de WordPress n'offre souvent pas les possibilités dont nous avons parfois besoin lorsque nous travaillons sur un site Web, notamment lorsqu'il s'agit d' optimiser les performances , l'un des points les plus importants lors du classement de notre site dans un moteur de recherche comme Google et surtout maintenant que Web Vitals est en place. et courir.

Mais il est clair que si nous avons un site personnel sur lequel nous sommes seuls à travailler, il n'est pas nécessaire de le migrer vers une configuration sans tête. Cependant, si plus de personnes sont impliquées dans ce projet (pas seulement des développeurs mais des créateurs de contenu ou des équipes marketing), nous devrions envisager d'adopter Headless CMS.

Comment un Headless CMS peut-il nous aider à améliorer les performances de notre site Web et la qualité de notre projet front-end ?

• En vous permettant de développer le front-end de manière complètement indépendante de la plateforme sur laquelle vous éditez votre contenu.

  La technologie que vous choisissez est votre propre choix , si vous vouliez mettre à niveau votre projet vers le dernier framework front-end, vous ne seriez pas dépendant d'un back-end et pourriez le faire sans avoir à repenser les migrations.

• Vous permettant de créer des projets multiplateformes sans avoir à dépendre de différents panneaux d'administration.

  En fin de compte, si pour une application vous avez besoin d'une description plus courte que le site Web principal, vous pouvez toujours utiliser un nouveau champ "short_description" et simplement le représenter sur le front-end de cette application spécifique.

• Il est destiné à faciliter le développement et à simplifier le processus de création d'un site, ainsi que sa mise à l'échelle.

  En isolant complètement le front-end, nous pouvons modifier l'apparence visuelle de l'ensemble de notre application sans modifier la structure de notre contenu.

• Offrir toujours des services qui nous permettront d' optimiser nos actifs et la rapidité de réponse avec laquelle ils nous sont servis. En fin de compte, toutes nos données seront livrées via les réseaux CDN.

Un réseau de diffusion de contenu (CDN) est un réseau distribué géographiquement de serveurs proxy et de leurs centres de données. L'objectif est de fournir une disponibilité et des performances élevées en répartissant le service dans l'espace par rapport aux utilisateurs finaux.

"

Que se passe-t-il si nous sommes préoccupés par la façon dont cela fonctionnera avec la structure de notre marque ou de notre entreprise ?

• En plus de prendre en charge les applications multiplateformes, cela nous permet également de maintenir la cohérence de la marque .

  Avoir le front-end comme projet de base et avoir plusieurs espaces dans un CMS sans tête, vous permet d'avoir une cohérence entre vos produits et facilite l'évolutivité car nous avons moins de code à maintenir.

• Bien que tous les CMS headless n'aient pas cet avantage, le CMS headless vers lequel nous migrons, Storyblok, dispose d'un éditeur visuel, qui permet de créer une indépendance entre les équipes . Les éditeurs ou les créateurs de contenu peuvent accéder au panneau pour modifier le contenu existant ou créer un nouveau contenu, en pouvant voir un aperçu de son apparence avant de le publier. Ainsi, ils n'auront pas à impliquer l'équipe de développement dans ce processus et pourront faire leur travail plus efficacement.

• Il rationalise également la gestion du contenu en vous permettant de configurer votre propre workflow de contenu . Vous pouvez définir les étapes par lesquelles un contenu doit passer avant d'être publié et, seulement lorsqu'il passe le processus avec succès, il sera publié.

Comment un CMS Headless peut-il gagner du temps par rapport à un CMS traditionnel ?

• Prendre soin de maintenir la sécurité de la plateforme et de la mettre à jour en votre nom. Chaque fois qu'il y a un bug ou que les utilisateurs ont besoin d'une nouvelle fonctionnalité, l'équipe derrière votre CMS Headless la développera pour vous, vous n'avez qu'à commencer à l'utiliser !
• Améliorer constamment l'expérience utilisateur (UX) et la conception (UI) pour vous, afin que les créateurs de contenu et les développeurs se sentent à l'aise pour créer de nouveaux champs, composants ou pages. Mais pas seulement sur l'aspect visuel, mais ils chercheront également à améliorer les performances de la base de données, afin que vous obteniez votre contenu instantanément et oubliez tout le travail que cela implique.

Monolithique vs sans tête

Après avoir vu les avantages qu'une configuration sans tête peut apporter à notre projet et aux personnes qui y travaillent, je pense qu'il est temps d'examiner les étapes dont nous avons besoin pour migrer notre projet.

Ce que vous devez garder à l'esprit lorsque vous partez sans tête

Comme nous l'avons déjà mentionné, Headless CMS permet une séparation nette des préoccupations entre les créateurs de contenu et les développeurs. De cette façon (dans un Headless CMS), le développeur se concentre sur la création de la structure de contenu, qui sera représentée dans le projet front-end, et l'éditeur sera en charge d'utiliser les composants et de les remplir de contenu dans le panneau d'administration .

Type de contenu que nous pouvons créer dans un CMS sans tête

1. Types d'entrée ou de modèle

Semblable aux types de publication personnalisés dans WordPress mais avec plus de liberté et d'extensibilité en ce qui concerne les types de données et les éditeurs.

Lorsque vous créez une nouvelle entrée de contenu dans votre tableau de bord, vous vous attendez à pouvoir choisir son type en fonction de la situation. Par exemple, si vous avez un site Web avec un blog, vous voudrez avoir plusieurs types de modèles, un pour les pages avec des listes ou du contenu dynamique appelé « page » et un pour chaque entrée de blog « article ».

Selon le CMS headless que vous avez choisi, le nom variera mais le concept est le même. Dans Storyblok, ces types d'entités sont appelés Type de contenu . « Types de contenu » définit le type d'entrée de contenu et peut contenir les champs de base pour vos entrées de contenu. Par défaut, nous avons un type de contenu "Page".

2. Composants réutilisables

Dans un Headless CMS, vous pouvez créer, en plus des types de contenu, des composants imbriqués et les réutiliser entre les types de contenu et d'autres composants. Dans Storyblok, ce type de composant — comme vous l'avez peut-être remarqué d'après son nom — s'appelle Blok .

Pour les utiliser dans un type de contenu tel qu'une page, vous devrez créer un champ dans le schéma des blocs de type. Ce champ vous permet d'ajouter des composants imbriqués à votre page tout en ajoutant du contenu.

Mais, en principe, nous n'aurons pas besoin de tels composants lors de la migration. Il vous donne simplement la flexibilité de créer des applications robustes et dynamiques sans avoir à impliquer le développeur.

Par exemple, lorsqu'un membre de l'équipe marketing souhaite ajouter un nouveau héros à la page À propos de nous, si le composant Héros a été créé comme imbriqué et que la page comporte un champ Blocs, le responsable marketing peut ajouter le héros sans avoir à impliquer le développeur.

Rendu des données provenant du CMS sans tête

Comme nous définissons la structure de notre contenu dans le panneau Headless CMS, nous devons considérer avec quel framework nous voulons créer notre projet front-end et quel client HTTP nous utiliserons.

Lors du choix d'un cadre, nous devons prendre en compte plusieurs facteurs :

Mon équipe et moi-même connaissons-nous cette technologie ?

Est-ce que cela me permet de rendre mon contenu dans le type de rendu dont mon projet a besoin ?

A-t-il des plugins ou des modules qui facilitent l'intégration avec le Headless CMS que j'utilise ?

Dans la plupart des cas, un site statique suffira et sera toujours la réponse la plus économique et la plus performante. Ainsi, il vous suffit de rechercher un générateur de site statique pour la technologie que vous connaissez, par exemple, Nuxt pour Vue ou Next pour la bibliothèque React.

En reliant ces deux éléments, un CMS sans tête et un constructeur de site statique sont considérés comme un ensemble de meilleures pratiques de développement Web axées sur la fourniture des meilleures performances, de la sécurité et du coût le plus bas. Cette architecture est également connue sous le nom de Jamstack. Il s'agit d'une architecture conçue pour rendre le Web plus rapide, plus sûr et plus facile à faire évoluer. Il s'appuie sur de nombreux outils et flux de travail que les développeurs adorent et qui apportent une productivité maximale.

En utilisant les frameworks tendances, vous serez assuré d'avoir un guide d'intégration avec le CMS Headless avec lequel vous allez travailler, et la plupart d'entre eux ont déjà un module ou un package qui vous permet d'obtenir des informations de l'API et dans de nombreux cas le prolonger.

Il ne vous reste plus qu'à définir la structure de vos composants concernant la façon dont vous avez structuré les données dans votre Headless CMS et automatiser le processus de publication de contenu. Par exemple, en utilisant les Webhooks que le CMS Headless vous fournit, vous pourrez démarrer un processus de construction dans votre hébergement préféré par ses crochets de construction une fois le contenu publié.

Temps dont vous aurez besoin

Comme pour toute migration, le temps nécessaire dépendra toujours proportionnellement de la complexité de votre projet. Si nous parlons d'un site WordPress commun, vous n'aurez qu'à migrer les types de publication que vous avez définis ou qui y sont fournis par défaut, tels que les pages, les publications et les catégories, ainsi que leur contenu.

Si, en revanche, vous avez personnalisé votre projet avec plusieurs plugins, vous devrez les développer via le projet front-end ou en utilisant ceux fournis par votre CMS Headless. Par exemple, si nous sommes soucieux du référencement et que nous utilisons donc Yoast SEO sur WordPress, nous aurons le plugin Field-Type SEO dans Storyblok pour nous aider dans la transition, mais nous devrons encore développer notre sitemap dans le front-end avec un guide pour nous aider.

Au final, tout le fardeau du développement incombera au projet frontal, car la mise en place du CMS Headless ne prendra pas beaucoup de temps.

Mais arrêtons de parler et regardons-le !

Étapes pour migrer notre contenu de WordPress vers Storyblok

La migration consistera en quatre étapes, de la création d'un espace dans notre nouveau Headless CMS Storyblok à la représentation du contenu migré dans notre projet front-end, que nous verrons en détail ci-dessous et dans lequel je vous laisserai des ressources pour faciliter la migration pour vous.

Commençons!

1. Créer un espace dans Storyblok

Pour créer un espace dans Storyblok, vous devez d'abord avoir un compte. Pour ce faire, vous devrez sélectionner le plan qui vous convient le mieux.

Accédez à la page Tarification et commencez par le plan qui correspond le mieux à vos besoins ou essayez le plan gratuit pour tester.

Créez votre compte, et vous pourrez accéder au panel.

Choisissez "Créer un nouvel espace" et commençons !

L'espace est un référentiel de contenu. Considérez-le comme un endroit où conserver tout le contenu lié à un projet. Chaque espace a ses propres composants, sources de données, actifs, environnements, domaines, collaborateurs et autorisations.

Prenez le temps d'explorer les sections de la barre latérale gauche. Commencez par parcourir les éléments suivants :

• Contenu , ce sera le dossier où sera stocké le contenu, là où l'équipe marketing passera le plus clair de son temps.
• Assets , où toutes les images seront stockées, que vous pourrez ensuite obtenir via le service CDN, optimisées et de n'importe quelle taille.
• Composants , où vous créerez les types de contenu et les composants imbriqués .
• Paramètres , la section où vous pourrez configurer les données de votre espace ainsi que les langues de votre application, les workflows que vous souhaitez que votre contenu suive avant d'être publié, les autorisations des utilisateurs, etc. Disons que cette zone sera la un lié à l'équipe informatique du projet.

Si vous souhaitez toujours explorer toutes les options du tableau de bord avant de plonger dans la migration, je vous recommande de jeter un œil à Comprendre l'interface utilisateur par Storyblok.

Maintenant que vous en savez un peu plus sur l'écosystème Storyblok, il est temps de définir à quoi ressemblera le contenu de notre application.

2. Définir des modèles

Pour migrer le contenu WordPress vers Storyblok, l'étape suivante consiste à créer les schémas qui définissent la structure de données WP en créant des Post Types dans l'espace Storyblok.

Commençons par les pages et les publications (les principaux types de publications dans n'importe quel site WP), que nous appellerons page et post dans Storyblok.

Le schéma des pages dans WP contient les champs : title , slug , feature image , date et content .

Remarque : Pour voir tous les champs contenus dans un type de publication, accédez au schéma dans les références de schéma de l'API REST WP.

Ce que vous devez savoir, c'est que, par défaut, tout type de contenu dans Storyblok aura des champs déjà définis pour vous, tels que Nom , Slug , Balises , Date de première publication , etc.

Ces champs pourraient être utilisés pour migrer le contenu de WP. Vous n'aurez qu'à l'étendre en ajoutant feature_image et content dans le type de contenu de page.

Rendez-vous dans la section Composants de votre espace, cliquez sur la page créée par défaut, supprimez le champ body et ajoutez feature_image comme type Assets > Images et content as Rich-text .

Une fois le schéma de la page prêt, passons au post . Pour le type de contenu de publication, il est nécessaire d'inclure plus d'informations, telles que feature_image , extract , content et les relations avec d'autres types tels que Authors ou Categories .

Étant donné que les auteurs et les catégories auront également leur propre contenu, accédez à la section Contenu dans la barre latérale et créez quelques dossiers appelés auteurs et catégories .

Chacun des dossiers doit être associé à un type de contenu par défaut. Pour cela, dans la section Composants , créez Auteur et Catégorie comme nouveaux Types de contenu, puis associez le Type de contenu relatif à chaque dossier en cliquant sur les trois points à droite du dossier et en sélectionnant Paramètres.

De cette manière, dans le type de contenu de publication, vous pouvez ajouter un champ à option unique ou à options multiples avec des histoires source et pointer vers le dossier créé pour chaque champ :

• Auteurs
  Cela spécifie le dossier où ils se trouvent authors/ .
• Catégories
  Ceci spécifie le dossier où ils se trouvent categories/ .

Note : Si vous souhaitez en savoir plus sur cette relation, consultez l'article Relation Auteurs et Articles.

Maintenant que vous avez vu comment créer quelques types de contenu et comment créer des relations entre eux, vous devrez définir le reste des modèles en suivant les mêmes étapes.

Ajout d'un type de contenu : global

Et vous vous demandez, qu'en est-il du contenu que toutes mes pages partageront ? Vous aimez le menu de navigation, le pied de page et d'autres éléments communs ?

Rassurez-vous, Storyblok y a déjà pensé et nous propose un guide simple pour définir dynamiquement nos éléments globaux. Il nous montre comment créer un type de contenu global et comment l'utiliser dans la section Contenu .

3. Migrer le contenu

Il est maintenant temps de commencer à migrer le contenu que vous avez stocké. Pour accéder au contenu WP, vous devez accéder à l'API REST JSON. Accédez au chemin /wp-json , si le projet est déployé, ou ?rest_route=/ si local.

Dans le cas où aucun des deux itinéraires ne fonctionne, inspectez le HTML de votre page pour un lien dans la tête avec rel="https://api.w.org/" , comme indiqué dans le guide de découverte WP, et obtenez le bon .

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

Pour nous aider lors de la migration, les développeurs de Storyblok nous ont fourni un plugin qui nous épargnera beaucoup de travail. Ce plugin s'appelle wordpress-importer, sur celui-ci, il est possible de définir le Content Type équivalent dans Storyblok pour le type WP Post à migrer, et il va le pousser vers notre espace et migrer les images vers notre section Assets pour nous.

Remarque : L'utilisation de ce script nécessite le nœud ≥14.0.0 car il utilise un chaînage optionnel.

Création du script de migration

La première chose à faire est de cloner le référentiel. Ensuite, installez les packages NPM, en utilisant npm install ou yarn , et créez un fichier à la racine du projet en tant que migrateWPtoStoryblok.js . Pour exécuter le script, vous avez besoin d'un script dans package.json pour l'exécuter, ajoutez :

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

Une fois que tout est prêt, il est temps de commencer à définir le script en suivant les spécifications README. Et, comme vous pouvez le voir, la prochaine chose qui sera nécessaire est de trouver le Space_id et le jeton OAuth pour se connecter à l'espace Storyblok.

• Le Space_id se trouve dans la section Paramètres de la barre latérale, dès que vous cliquez dessus, vous le verrez sur le côté droit.
• Pour générer le jeton OAuth , vous devez vous rendre en haut de la barre latérale, cliquer sur la petite flèche juste à côté du logo Storyblok, et aller sur Mon compte . Si nous faisons défiler vers le bas, nous verrons la section Jetons d'accès personnels , en générer un et le copier.

Lorsque vous avez obtenu les deux secrets, vous pouvez les ajouter au début du script avec l'URL de l'API JSON de votre projet :

 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 })

Comme décrit dans les sections précédentes, le type de contenu de page dans Storyblok est l'équivalent du type de publication dans les pages WP. Dans le bloc de code ci-dessous, vous verrez où vous devrez spécifier chacun.

Et, une fois le type de publication et le type de contenu définis, il est temps de spécifier le nom des champs utilisés dans ce type d'entité dans WP et le nom équivalent dans Storyblok, dans l'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" } } ] })

Note : Pour que la migration fonctionne correctement, assurez-vous que les permaliens sont sélectionnés par le nom de l'entrée et pas aussi simple. Sinon, le script ne créera pas la relation parent-enfant entre les pages.

Dans le schema_mapping vous pouvez définir plusieurs types de champs, ceux-ci peuvent être :

• Un champ simple , tel que title .
• Une sous-propriété d'un champ, comme dans ce cas l'URL de l'image caractéristique.
  Note : Le plugin se charge lui-même de migrer les images vers l'espace Storyblok via l'URL associée dans links.wp:featuredmedia.0 .

• Un champ a migré vers un bloc imbriqué dans Storyblok.

  Imaginez que vous souhaitiez créer un composant dans Storyblok pour définir le texte enrichi de votre site afin que tous les types de publication qui l'utilisent aient le même style et les mêmes options.

  Pour cela, vous pouvez utiliser le format d'objet et spécifier le nom du champ dans le modèle Storyblok sous la propriété field , le nom du composant que vous souhaitez stocker dans ce champ et le nom du champ dans le composant où le contenu seront migrés.

 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()

Page Type d'entrée

Maintenant que vous savez comment définir les types de champs, pour le schéma de page, cela ressemblerait au bloc de code ci-dessous.

Le plugin s'occupera de la relation parent-enfant entre les pages en créant un dossier dans Storyblok sous le slug du parent et en associant le parent comme la maison de ce dossier.

De plus, si le champ de contenu contient des images , le plugin le migrera également pour vous !

 { 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", } }

Type d'entrée

Les articles ont un schéma similaire aux pages mais, dans ce cas, pour les stocker dans un dossier, vous devez définir le nom du dossier sous le type d'entrée :

 { 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", } }

Catégorie de type d'entrée

Et une fois le schéma des publications défini, il est logique de définir le schéma des catégories afin qu'elles puissent être associées comme décrit dans la section précédente.

Afin de définir le dossier qui les contient comme catégories et non comme catégorie, leur nom par défaut, il faut aller dans l'option Permaliens dans l'admin WordPress et changer l'option Catégories de base en categories . Ensuite, le champ multi-options des entrées Post sera celui qui a la relation avec les catégories correspondantes.

Note : Ces étapes sont les mêmes que celles à suivre pour migrer des auteurs et les lier aux articles.

 { 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", } }

Script final complet

Le code ci-dessous sera le script de migration résultant d'un projet WP avec les types de base vers l'espace Storyblok que nous avions créé.

 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. Créer un projet frontal

Maintenant que le contenu est déjà stocké dans le tableau de bord Storyblok, il est temps de connecter le projet Front-end à Storyblok.

Quel que soit votre framework ou votre bibliothèque JS, Storyblok fournit le client JavaScript qui vous aidera dans l'intégration. De plus, dans le cas où vous utilisez un framework spécifique, vous trouverez d'autres packages qui vous faciliteront la tâche, comme dans Nuxt le module storyblok-nuxt .

Cette API JavaScript inclura également un pont entre Storyblok et votre application Front-end. Le pont est chargé de communiquer via iframe avec Storyblok pour indiquer à l'interface d'édition quel composant ouvrir lorsque l'utilisateur clique dessus.

Voici une liste de tutoriels que vous pouvez trouver sur Storyblok pour connecter votre projet Front-end.

Note : Si vous ne trouvez pas votre technologie parmi eux, ne vous inquiétez pas il existe de nombreux autres tutoriels sur le site de Storyblok, recherchez le vôtre dans le moteur de recherche, et si vous n'en trouvez pas je vous encourage à les contacter, et vous aiderez beaucoup plus de gens !

• Suivant
• Gatsby
• vue
• Nuxt
• Angulaire
• Svelte
• braise
• AMP

5. Hébergez votre projet frontal et automatisez le déploiement

Une fois votre projet prêt à passer en production, vous choisissez un hébergeur et liez votre référentiel pour un déploiement facile, puis vous vous demandez :

Comment redéployer mon site statique si je publie une entrée sur Storyblok ?

La réponse est très simple : en utilisant les webhooks proposés par Storyblok et les build hooks de votre hébergement.

Pour vous donner un exemple réel, vous pouvez créer des URL de build hooks dans Netlify dans la section de déploiement ; l'URL créée pour Storyblok dans les crochets de construction ira dans le champ Paramètres → Webhooks → Histoire publiée et non publiée de l'espace Storyblok.

Guides et outils que nous avons utilisés pendant la migration

Récapitulons les liens qui ont aidé à la migration du contenu et ceux qui ont aidé à comprendre le fonctionnement de l'API REST et du CMS headless vers lequel vous migrez.

Documentation de l'API WP REST requise

API REST

• Référence du point de terminaison du développeur d'API REST
• Utilisation de l'API REST
• Découvrir l'API et son parcours

Schémas

• Référence du schéma de page
• Référence de post-schéma
• Référence du schéma des catégories

Migrer vers Storyblok

Informations générales

• Le site officiel de Storyblok
• Tarifs et forfaits Storyblok

Documentation

• Comprendre l'interface utilisateur
• Structures de contenu
• Configuration de la structure du contenu du blog dans Storyblok

Composants globaux

• Comment créer une navigation de menu d'en-tête de site Web avec Storyblok
• Le pont Storyblok V2

Lié au référencement

• Comment générer un sitemap a445r avec un CMS headless ?
• https://www.storyblok.com/apps/seo

Webhooks et crochets de construction

• Tout sur les Webhooks
• Comment utiliser les webhooks Storyblok
• Hooks de construction d'hébergement - Exemple Netlify

Scripts et packages

• SDK JavaScript universel pour l'API de Storyblok : https://github.com/storyblok/storyblok-js-client
• Aide à la migration de WP vers Storyblok : https://github.com/storyblok/wordpress-importer

Jamstack

• Le site Jamstack
• Une liste de générateurs de sites statiques pour les sites Jamstack

Conclusion

Après avoir lu cet article, vous aurez ce dont vous avez besoin pour comprendre pourquoi une configuration sans tête améliorera votre projet, comment migrer de votre projet WordPress vers un CMS sans tête comme Storyblok et comment continuer à améliorer et étendre votre projet.

Comme vous l'avez vu, les possibilités d'une configuration sans tête sont infinies . 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?