Come migrare da WordPress a un CMS senza testa

Questo articolo è stato gentilmente supportato dai nostri cari amici di Storyblok, un simpatico CMS headless con un editor visivo, componenti nidificati e blocchi di contenuto personalizzabili per siti Web e app. Grazie!

WordPress è il costruttore di siti Web più utilizzato al mondo; quasi la metà del web ha utilizzato WordPress per creare il proprio sito web. Ha senso, perché ti consente di creare rapidamente siti Web e dispone di un ricco ecosistema di plug-in per aiutarti a ridimensionare il tuo sito.

Ma la tecnologia si sta evolvendo e ci sono sempre più opzioni che semplificano la creazione di siti Web. Inoltre, ci danno la possibilità di migliorare le prestazioni del sito Web e di avere maggiore controllo e sicurezza sull'applicazione.

L' architettura iniziale di WordPress è monolitica , quindi l'interfaccia utente e l'accesso ai dati sono combinati sulla stessa piattaforma.

Dall'introduzione dell'API REST su WordPress, può essere utilizzata in modo headless, consentendo agli sviluppatori di utilizzarla come back-end e avere il front-end in un progetto diverso.

In questo modo disaccoppiato, modelli e controller sono raggruppati sul lato WordPress , gestendo la manipolazione dei dati e l'interazione con il database. Nel frattempo, il front-end interagisce solo con l'API REST tramite un client HTTP.

Ma questo ha anche alcuni svantaggi, è comunque necessario configurare e aggiornare WordPress, renderlo sicuro e dipendere dalla loro tecnologia per lo sviluppo di nuove funzionalità.

Letture correlate su SmashingMag

Per quelli di voi che stanno appena iniziando nel mondo senza testa, questi articoli ti aiuteranno a capire i dettagli dietro e perché tutti stanno iniziando a migrare.

• "CMS senza testa spiegato in 5 minuti effettivi"
• "Ripensa la tua strategia di contenuto per un CMS senza testa"
• "Come pensare in componenti può aumentare la tua produttività"
• Un elenco curato di articoli relativi a “Headless” →

Ma perché migrare su un CMS senza testa?

Tenendo conto del fatto che questo articolo mostrerà come migrare da WordPress a un CMS Headless, WordPress è probabilmente la tua configurazione attuale.

Un CMS Headless ci darà la libertà di concentrarci solo sul progetto front-end , potendo scegliere la tecnologia che conosciamo e sulla struttura dei nostri dati. Alla fine, si occupa della gestione dei contenuti e della consegna dei contenuti, in modo che possiamo occuparci della parte di rendering.

"Un Headless CMS è un sistema che fornisce le stesse funzionalità di un Content Management System (CMS) e altro, il tutto esposto tramite un'API."

Questo tipo di configurazione è particolarmente utile per le aziende che hanno più sedi e desiderano ridurre i costi o semplificare i processi. Un'architettura headless consente a queste aziende di centralizzare la gestione dei contenuti in un'unica interfaccia di amministrazione , fornendo le API che verranno utilizzate dalle diverse pagine Web dell'azienda.

Un altro uso comune di un'architettura headless è creare un progetto front-end che rappresenti il ​​marchio aziendale. In questo modo, tutti i prodotti lanciati dall'azienda avranno lo stesso aspetto grafico, ma ognuno avrà il proprio contenuto, gestito nello stesso pannello di amministrazione.

Nota : questo esempio può essere facilmente visto su siti Web di conferenze come JSWorld Conference e VueJS Amsterdam che, essendo degli stessi creatori, il progetto front-end è lo stesso, cambia solo il contenuto.

Diversamente da un CMS come WordPress, in un CMS Headless hai un pannello di amministrazione già configurato e mantenuto , e talvolta anche ospitato, per te. Per iniziare a creare contenuti, devi solo creare un account, accedere e sarai in grado di creare, modificare, duplicare ed eliminare i tuoi contenuti, gestire utenti, tradurre contenuti e lavorare con i flussi di lavoro di pubblicazione, tra le altre cose.

Un CMS headless renderà più facile per le persone del tuo team comprendere il flusso di lavoro, siano essi creatori di contenuti o marketer, qualcosa da tenere a mente se non sei l'unico a modificare il contenuto.

Vale la pena notare che alcuni CMS Headless non si concentrano solo sull'offrirti i servizi già offerti da un CMS come WordPress. Fornisce inoltre servizi come CDN di immagini per ridimensionare o riformattare le immagini al volo o ulteriore sicurezza tramite i backup S3.

Avere questa configurazione non solo ti darà libertà, sicurezza e comfort, ma migliorerà anche le prestazioni della tua applicazione senza servizi di terze parti. Solo collegando il tuo progetto front-end tramite un client HTTP e ottenendo i componenti e i dati, sarai pronto e funzionante.

I vantaggi di andare senza testa e quando ha senso

L'architettura di WordPress spesso non offre le possibilità di cui a volte abbiamo bisogno quando si lavora su un sito Web, soprattutto quando si tratta di ottimizzare le prestazioni , uno dei punti più importanti quando si classifica il nostro sito in un motore di ricerca come Google e soprattutto ora che Web Vitals è attivo e correndo.

Ma è chiaro che se abbiamo un sito personale su cui lavoriamo solo noi stessi, non è necessario migrarlo su una configurazione headless. Tuttavia, se più persone sono coinvolte in quel progetto (non solo sviluppatori ma creatori di contenuti o team di marketing), allora dovremmo prendere in considerazione l'adozione di Headless CMS.

In che modo un CMS Headless può aiutarci a migliorare le prestazioni del nostro sito Web e la qualità del nostro progetto front-end?

• Consentendoti di sviluppare il front-end in modo completamente indipendente dalla piattaforma in cui modifichi i tuoi contenuti.

  La tecnologia che scegli è una tua scelta , se volessi aggiornare il tuo progetto all'ultimo framework front-end, non dipenderesti da un back-end e potresti farlo senza dover ripensare le migrazioni.

• Consente di creare progetti multipiattaforma senza dover dipendere da diversi pannelli di amministrazione.

  Alla fine, se per un'app hai bisogno di una descrizione più breve rispetto al sito web principale, puoi sempre utilizzare un nuovo campo "short_description" e rappresentarlo semplicemente sul front-end di quella specifica app.

• Ha lo scopo di semplificare lo sviluppo e semplificare il processo di creazione di un sito, nonché di ridimensionarlo.

  Avendo il front-end completamente isolato possiamo cambiare l'aspetto visivo della nostra intera applicazione senza modificare la struttura del nostro contenuto.

• Offrendo sempre servizi che ci consentiranno di ottimizzare i nostri asset e la velocità di risposta con cui ci vengono serviti. Alla fine tutti i nostri dati verranno consegnati tramite reti CDN.

Una rete di distribuzione dei contenuti (CDN) è una rete geograficamente distribuita di server proxy e relativi data center. L'obiettivo è fornire disponibilità e prestazioni elevate distribuendo il servizio spazialmente rispetto agli utenti finali.

“

E se fossimo preoccupati per come funzionerà con la struttura del nostro marchio o della nostra azienda?

• Oltre a supportare le applicazioni multipiattaforma, ci consente anche di mantenere la coerenza del marchio .

  Avere il front-end come progetto di base e avere più spazi in un CMS Headless, ti consente di avere coerenza tra i tuoi prodotti e semplifica la scalabilità perché abbiamo meno codice da mantenere.

• Sebbene non tutti i CMS senza testa abbiano questo vantaggio, il CMS senza testa a cui stiamo migrando, Storyblok, ha un editor visivo, che consente di creare indipendenza tra i team . Gli editori o i creatori di contenuti possono accedere al pannello per modificare i contenuti esistenti o creare nuovi contenuti, potendo vedere un'anteprima di come apparirà prima della pubblicazione. In questo modo non dovranno coinvolgere il team di sviluppo in questo processo e potranno svolgere il proprio lavoro in modo più efficiente.

• Semplifica inoltre la gestione dei contenuti consentendo di impostare il proprio flusso di lavoro dei contenuti . Puoi definire le fasi che un contenuto deve attraversare prima di essere pubblicato e, solo quando supera il processo con successo, verrà pubblicato.

In che modo un CMS Headless può risparmiare tempo rispetto a un CMS tradizionale?

• Prendersi cura di mantenere la sicurezza della piattaforma e aggiornarla per tuo conto. Ogni volta che c'è un bug o gli utenti richiedono una nuova funzionalità, il team dietro il tuo CMS Headless lo svilupperà per te, devi solo iniziare a usarlo!
• Migliorare costantemente l'esperienza utente (UX) e il design (UI) per te, in modo che i creatori di contenuti e gli sviluppatori si sentano a proprio agio nel creare nuovi campi, componenti o pagine. Ma non solo sull'aspetto visivo, ma cercheranno anche di migliorare le prestazioni del database, in modo da ottenere il contenuto all'istante e dimenticare tutto il lavoro che è coinvolto.

Monolitico vs senza testa

Avendo visto i vantaggi che una configurazione senza testa può apportare al nostro progetto e alle persone che ci lavorano, penso che sia giunto il momento di esaminare i passaggi di cui abbiamo bisogno per migrare il nostro progetto.

Cosa devi tenere a mente quando vai senza testa

Come abbiamo già accennato, Headless CMS consente una netta separazione delle preoccupazioni tra creatori di contenuti e sviluppatori. In questo modo (in un CMS Headless), lo sviluppatore si concentra sulla creazione della struttura dei contenuti, che sarà rappresentata nel progetto front-end, e l'editor si occuperà di utilizzare i componenti e riempirli di contenuto nel pannello di amministrazione .

Tipo di contenuto che possiamo creare in un CMS senza testa

1. Tipi di voce o modello

Simile ai tipi di post personalizzati in WordPress ma con maggiore libertà ed estensibilità quando si tratta di tipi di dati ed editor.

Quando vai a creare una nuova voce di contenuto nella tua dashboard, ti aspetti di poter scegliere quale tipo dipende dalla situazione. Ad esempio, se hai un sito web con un blog, vorrai avere diversi tipi di modelli, uno per le pagine con elenchi o contenuto dinamico chiamato " pagina " e uno per ogni post del blog.

A seconda del CMS headless che hai scelto, il nome varierà ma il concetto è lo stesso. In Storyblok questi tipi di entità sono chiamati Tipo di contenuto . "Tipi di contenuto" definisce il tipo di immissione di contenuto e può contenere i campi di base per le voci di contenuto. Per impostazione predefinita, abbiamo un tipo di contenuto "Pagina".

2. Componenti riutilizzabili

In un CMS senza testa, puoi creare, oltre ai tipi di contenuto, componenti nidificati e riutilizzarli tra tipi di contenuto e altri componenti. In Storyblok, questo tipo di componente, come avrai notato dal nome, si chiama Blok .

Per utilizzarli in un tipo di contenuto come una pagina, dovrai creare un campo nello schema dei blocchi di tipo. Questo campo ti consente di aggiungere componenti nidificati alla tua pagina mentre aggiungi contenuto.

Ma, in linea di principio, non avremo bisogno di tali componenti durante la migrazione. Ti dà semplicemente la flessibilità per creare applicazioni robuste e dinamiche senza dover coinvolgere lo sviluppatore.

Ad esempio, quando un membro del team di marketing vuole aggiungere un nuovo Eroe alla pagina Chi siamo, se il componente Eroe è stato creato come nidificato e la pagina ha un campo Blocchi, l'addetto al marketing può aggiungere l'Eroe senza dover coinvolgere il sviluppatore.

Rendering dei dati provenienti dal CMS senza testa

Mentre definiamo la struttura dei nostri contenuti nel pannello Headless CMS, dobbiamo considerare con quale framework vogliamo creare il nostro progetto front-end e quale client HTTP utilizzeremo.

Nella scelta di un framework dobbiamo tenere conto di diversi fattori:

Il mio team e io abbiamo familiarità con questa tecnologia?

Mi consente di eseguire il rendering dei miei contenuti nel tipo di rendering di cui ha bisogno il mio progetto?

Ha plugin o moduli che facilitano l'integrazione con il CMS Headless che sto usando?

Nella maggior parte dei casi sarà sufficiente un sito statico e sarà sempre la risposta più economica e performante. Quindi, devi solo cercare un generatore di siti statici per la tecnologia che conosci, ad esempio Nuxt per Vue o Next per la libreria React.

Collegando queste due cose, un CMS Headless e un costruttore di siti statici sono considerati un insieme di best practice per lo sviluppo web incentrate sulla fornitura delle massime prestazioni, sicurezza e costi più bassi. Questa architettura è anche conosciuta come Jamstack. È un'architettura progettata per rendere il Web più veloce, più sicuro e più facile da scalare. Si basa su molti degli strumenti e dei flussi di lavoro che gli sviluppatori amano e che portano la massima produttività.

Utilizzando i framework di tendenza, avrai la certezza di una guida all'integrazione con il CMS Headless con cui lavorerai e la maggior parte di essi ha già un modulo o un pacchetto che ti consente di ottenere informazioni dall'API e in molti casi estenderlo.

L'unica cosa che ti resta da fare è definire la struttura dei tuoi componenti riguardo a come hai strutturato i dati nel tuo CMS Headless e automatizzare il processo di pubblicazione dei contenuti. Ad esempio, utilizzando i Webhook forniti da Headless CMS, sarai in grado di avviare un processo di build nel tuo hosting preferito tramite i suoi build hook una volta che il contenuto è stato pubblicato.

Quantità di tempo di cui avrai bisogno

Come per qualsiasi migrazione, il tempo necessario dipenderà sempre proporzionalmente dalla complessità del tuo progetto. Se stiamo parlando di un comune sito WordPress, dovrai solo migrare i tipi di Post che hai definito o che vengono forniti di default in esso, come Pagine, Post e Categorie, e il loro contenuto.

Se invece hai personalizzato il tuo progetto con più plugin, dovrai svilupparli attraverso il progetto front-end o utilizzando quelli forniti dal tuo CMS Headless. Ad esempio, se siamo attenti alla SEO e quindi utilizziamo Yoast SEO su WordPress, avremo il plug-in Field-Type SEO in Storyblok per aiutarci nella transizione, ma dovremo comunque sviluppare la nostra mappa del sito nel front-end con una guida per aiutarci.

Alla fine, tutto l'onere dello sviluppo ricadrà sul progetto front-end, poiché la configurazione del CMS Headless non richiederà molto tempo.

Ma smettiamola di parlare e diamo un'occhiata!

Passaggi per migrare i nostri contenuti da WordPress a Storyblok

La migrazione consisterà in quattro passaggi, dalla creazione di uno spazio nel nostro nuovo Headless CMS Storyblok alla rappresentazione dei contenuti migrati nel nostro progetto front-end, che vedremo in dettaglio di seguito e in cui vi lascio risorse per semplificare la migrazione.

Iniziamo!

1. Creare uno spazio in Storyblok

Per creare uno spazio in Storyblok, devi prima avere un account. Per fare ciò, dovrai selezionare il piano più adatto a te.

Vai alla pagina Prezzi e inizia con il piano più adatto alle tue esigenze o prova il piano gratuito per il test.

Crea il tuo account e potrai accedere al pannello.

Scegli "Crea un nuovo spazio" e iniziamo!

Lo spazio è un repository di contenuti. Pensalo come un luogo in cui conservare tutti i contenuti relativi a un progetto. Ogni spazio ha i propri componenti, origini dati, risorse, ambienti, domini, collaboratori e autorizzazioni.

Prenditi del tempo per esplorare le sezioni sulla barra laterale sinistra. Inizia sfogliando quanto segue:

• Contenuto , questa sarà la cartella in cui verrà archiviato il contenuto, dove il team di marketing trascorrerà la maggior parte del tempo.
• Asset , dove verranno archiviate tutte le immagini, che potrai poi ottenere tramite il servizio CDN, ottimizzate e di qualsiasi dimensione.
• Componenti , dove creerai i tipi di contenuto ei componenti nidificati .
• Impostazioni , la sezione dove potrai configurare i dati del tuo spazio oltre che le lingue della tua applicazione, i flussi di lavoro che vuoi che i tuoi contenuti seguano prima di essere pubblicati, i permessi utente, ecc. Diciamo che quest'area sarà la uno relativo al team IT del progetto.

Se vuoi comunque esplorare tutte le opzioni della dashboard prima di immergerti nella migrazione, ti consiglio di dare un'occhiata a Capire l'interfaccia utente di Storyblok.

Ora che conosci un po' l'ecosistema Storyblok, è il momento di definire come apparirà il contenuto della nostra applicazione.

2. Definizione dei modelli

Per migrare i contenuti di WordPress su Storyblok, il passaggio successivo consiste nel creare gli schemi che definiscono la struttura dei dati del WP creando i tipi di post nello spazio Storyblok.

Iniziamo con pagine e post (i principali tipi di post in qualsiasi sito WP), che chiameremo page e post in Storyblok.

Lo schema delle pagine in WP contiene i campi: titolo , slug , immagine in evidenza , data e contenuto .

Nota : per visualizzare tutti i campi contenuti in un tipo di post, vai allo schema nei riferimenti dello schema dell'API REST di WP.

Quello che devi sapere è che, per impostazione predefinita, qualsiasi tipo di contenuto in Storyblok avrà alcuni campi già definiti per te, come Nome , Slug , Tag , Data di prima pubblicazione e così via.

Questi campi possono essere utilizzati per migrare il contenuto da WP. Dovrai solo estenderlo aggiungendo l' immagine_in primo piano e il contenuto nel tipo di contenuto della pagina.

Vai alla sezione Componenti nel tuo spazio, fai clic sulla page creata per impostazione predefinita, rimuovi il campo del corpo e aggiungi immagine_in evidenza come tipo Assets > Images e contenuto come Rich-text .

Una volta che lo schema della page è pronto, passiamo al post . Per il tipo di contenuto del post, è necessario includere più informazioni, come l' immagine_in primo piano, l' estratto , il contenuto e le relazioni con altri tipi come gli autori o le categorie .

Poiché anche Autori e Categorie avranno il proprio contenuto, vai alla sezione Contenuto nella barra laterale e crea un paio di cartelle chiamate autori e categorie .

Ciascuna delle cartelle deve avere un tipo di contenuto predefinito associato. Per fare ciò, nella sezione Componenti , crea Autore e Categoria come nuovi Tipi di contenuto, quindi associa il Tipo di contenuto relativo a ciascuna cartella cliccando sui tre punti a destra della cartella e selezionando Impostazioni.

In questo modo, nel Tipo di contenuto del post puoi aggiungere un campo Opzione singola o Multi-Opzioni con le Storie di origine e puntare alla cartella creata per ogni campo:

• Autori
  Specifica la cartella in cui si trovano authors/ .
• Categorie
  Questo specifica la cartella in cui si trovano categories/ .

Nota : se vuoi saperne di più su questa relazione, dai un'occhiata all'articolo Relazioni tra autori e articoli.

Ora che hai visto come creare un paio di tipi di contenuto e come creare relazioni tra di loro, dovrai definire il resto dei modelli seguendo gli stessi passaggi.

Aggiunta di un tipo di contenuto: Globale

E ti chiedi, che dire del contenuto che condivideranno tutte le mie pagine? Ti piace il menu di navigazione, il piè di pagina e altri elementi comuni?

Non preoccuparti, Storyblok ci ha già pensato e ci offre una semplice guida per definire dinamicamente i nostri elementi globali. Ci mostra come creare un tipo di contenuto globale e come utilizzarlo nella sezione Contenuto .

3. Migrazione del contenuto

Ora è il momento di iniziare a migrare il contenuto che hai archiviato. Per accedere al contenuto di WP è necessario accedere all'API REST JSON. Accedi al percorso /wp-json , se il progetto è distribuito, o ?rest_route=/ se locale.

Nel caso in cui nessuno dei due percorsi funzioni, controlla l'HTML della tua pagina per un collegamento in testa con rel="https://api.w.org/" , come indicato nella guida alla scoperta del WP, e ottieni quello corretto .

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

Per aiutarci durante la migrazione, gli sviluppatori di Storyblok ci hanno fornito un plugin che ci farà risparmiare molto lavoro. Questo plugin è chiamato wordpress-importer, su di esso è possibile definire il tipo di contenuto equivalente in Storyblok per il tipo WP Post da migrare, e lo spingerà nel nostro spazio e migrerà le immagini nella nostra sezione Risorse per noi.

Nota : l'utilizzo di questo script richiede il nodo ≥14.0.0 perché utilizza il concatenamento opzionale.

Creazione dello script di migrazione

La prima cosa da fare è clonare il repository. Quindi, installa i pacchetti NPM, utilizzando npm install o yarn e crea un file nella radice del progetto come migrateWPtoStoryblok.js . Per eseguire lo script è necessario uno script in package.json per eseguirlo, aggiungi:

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

Una volta che tutto è pronto, è il momento di iniziare a definire lo script seguendo le specifiche README. E, come puoi vedere, la prossima cosa che sarà necessaria è trovare Space_id e il token OAuth per connettersi allo spazio Storyblok.

• Lo Space_id si trova nella sezione Impostazioni della barra laterale, non appena fai clic su di esso, lo vedrai sul lato destro.
• Per generare il token OAuth , devi andare nella parte superiore della barra laterale, fare clic sulla piccola freccia accanto al logo Storyblok e andare su Il mio account . Se scorriamo verso il basso vedremo la sezione Token di accesso personali , ne genereremo uno e lo copieremo.

Dopo aver ottenuto entrambi i segreti, puoi aggiungerli all'inizio dello script insieme all'URL dell'API JSON del tuo progetto:

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

Come descritto nelle sezioni precedenti, il tipo di contenuto della pagina in Storyblok è l'equivalente del tipo di post nelle pagine del WP. Nel blocco di codice sottostante, vedrai dove dovrai specificarli.

E, una volta definiti il ​​tipo di post e il tipo di contenuto, è il momento di specificare il nome dei campi utilizzati in questo tipo di entità in WP e il nome equivalente in Storyblok, nell'opzione 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" } } ] })

Nota : Affinché la migrazione funzioni correttamente, assicurati che i permalink siano selezionati dal nome della voce e non così semplice. In caso contrario, lo script non creerà la relazione padre-figlio tra le pagine.

All'interno di schema_mapping puoi definire diversi tipi di campi, questi possono essere:

• Un campo semplice , come title .
• Una sottoproprietà di un campo, come in questo caso l'URL dell'immagine caratteristica.
  Nota : il plug-in stesso si occupa della migrazione delle immagini nello spazio Storyblok tramite l'URL associato in links.wp:featuredmedia.0 .

• Un campo è migrato in un blocco nidificato in Storyblok.

  Immagina di voler creare un componente in Storyblok per definire il rich text del tuo sito in modo che tutti i tipi di post che lo utilizzano abbiano lo stesso stile e le stesse opzioni.

  Per questo, puoi utilizzare il formato oggetto e specificare il nome del campo nel modello Storyblok sotto la proprietà del campo , il nome del componente che desideri memorizzare all'interno di quel campo e il nome del campo all'interno del componente in cui il contenuto verrà migrato.

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

Tipo di voce Pagina

Ora che sai come definire i tipi di campo, per lo schema della pagina sarebbe simile al blocco di codice sottostante.

Il plugin si occuperà della relazione genitore-figlio tra le pagine creando una cartella in Storyblok sotto lo slug del genitore e associando il genitore come home di quella cartella.

Inoltre, se il campo del contenuto contiene immagini , il plugin lo migrerà anche per te!

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

Tipo di voce Posta

I post hanno uno schema simile alle pagine ma, in questo caso, per salvarli in una cartella è necessario definire il nome della cartella sotto il tipo di voce:

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

Tipo di voce Categoria

E una volta definito lo schema per i post, ha senso definire lo schema per le categorie in modo che possano essere associate come descritto nella sezione precedente.

Per definire la cartella che li contiene come categorie e non come categoria, il loro nome predefinito, devi andare all'opzione Permalink nell'amministratore di WordPress e cambiare l'opzione di base Categorie in categories . Quindi il campo multi-opzione delle voci Post sarà quello che ha la relazione con le categorie corrispondenti.

Nota : questi passaggi sono gli stessi da seguire per migrare gli autori e collegarli agli articoli.

 { 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 finale completo

Il codice seguente sarà lo script di migrazione risultante da un progetto WP con i tipi di base allo spazio Storyblok che avevamo creato.

 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. Crea un progetto front-end

Ora che il contenuto è già archiviato nella dashboard di Storyblok, è il momento di collegare il progetto Front-end a Storyblok.

Qualunque sia il tuo framework o libreria JS, Storyblok fornisce il client JavaScript che ti aiuterà con l'integrazione. Inoltre, nel caso in cui utilizzi un framework specifico, troverai altri pacchetti che ti faciliteranno il percorso, come in Nuxt il modulo storyblok-nuxt .

Questa API JavaScript includerà anche un ponte tra Storyblok e la tua applicazione front-end. Il bridge è responsabile della comunicazione tramite iframe con Storyblok per indicare all'interfaccia di modifica quale componente aprire quando l'utente fa clic su di esso.

Ecco un elenco di tutorial che puoi trovare su Storyblok per collegare il tuo progetto Front-end.

Nota : Se non trovi la tua tecnologia tra queste, non ti preoccupare ci sono molti altri tutorial sul sito di Storyblok, cerca la tua nel motore di ricerca, e se non la trovi ti consiglio di contattarli, e aiuterai molte più persone!

• Prossimo
• Gatsby
• Vue
• Avanti
• Angolare
• Svelto
• Brace
• AMP

5. Ospita il tuo progetto front-end e automatizza la distribuzione

Una volta che il tuo progetto è pronto per andare in produzione, scegli un provider di hosting e colleghi il tuo repository per una facile distribuzione, quindi ti chiedi:

Come faccio a ridistribuire il mio sito statico se pubblico una voce su Storyblok?

La risposta è molto semplice: utilizzando i webhook offerti da Storyblok e i build hook del tuo hosting.

Per darti un esempio reale, puoi creare URL di hook di build in Netlify all'interno della sezione di distribuzione; l'URL creato per Storyblok negli hook di build andrà nel campo Impostazioni → Webhook → Storia pubblicata e non pubblicata nello spazio Storyblok.

Guide e strumenti che abbiamo utilizzato durante la migrazione

Ricapitoliamo i link che hanno aiutato nella migrazione dei contenuti e quelli che hanno aiutato a capire il funzionamento dell'API REST e del CMS headless a cui si sta migrando.

Documentazione dell'API REST WP necessaria

API REST

• Riferimento dell'endpoint per sviluppatori API REST
• Utilizzo dell'API REST
• Alla scoperta dell'API e del suo percorso

Schemi

• Riferimento allo schema della pagina
• Post di riferimento allo schema
• Riferimento allo schema delle categorie

Migrazione a Storyblok

Informazioni generali

• Il sito ufficiale di Storyblok
• Prezzi e piani di Storyblok

Documentazione

• Comprendere l'interfaccia utente
• Strutture di contenuto
• Impostazione della struttura del contenuto del blog in Storyblok

Componenti globali

• Come creare una navigazione nel menu dell'intestazione di un sito Web con Storyblok
• Il ponte Storyblok V2

Correlati alla SEO

• Come generare una Sitemap a445r con un CMS headless?
• https://www.storyblok.com/apps/seo

Webhook e Build Hook

• Tutto sui Webhook
• Come utilizzare i webhook Storyblok
• Hosting build hook - Esempio Netlify

Script e pacchetti

• SDK JavaScript universale per l'API di Storyblok: https://github.com/storyblok/storyblok-js-client
• Migrazione da WP a Storyblok helper: https://github.com/storyblok/wordpress-importer

Jamstack

• Il sito Jamstack
• Un elenco di generatori di siti statici per i siti Jamstack

Conclusione

Dopo aver letto questo articolo avrai ciò di cui hai bisogno per capire perché una configurazione senza testa migliorerà il tuo progetto, come migrare dal tuo progetto WordPress a un CMS senza testa come Storyblok e come continuare a migliorare ed estendere il tuo progetto.

Come hai visto, le possibilità di una configurazione senza testa sono infinite . 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?