Cum să migrați de la WordPress la un CMS fără cap

Acest articol a fost susținut cu amabilitate de dragii noștri prieteni de la Storyblok, un CMS prietenos fără cap, cu un editor vizual, componente imbricate și blocuri de conținut personalizabile pentru site-uri web și aplicații. Mulțumesc!

WordPress este cel mai folosit constructor de site-uri web din lume; aproape jumătate din web a folosit WordPress pentru a-și crea site-ul. Are sens, deoarece vă permite să creați rapid site-uri web și are un ecosistem bogat de pluginuri pentru a vă ajuta să vă scalați site-ul.

Dar tehnologia evoluează și există din ce în ce mai multe opțiuni care facilitează crearea de site-uri web. Mai mult, ele ne oferă posibilitatea de a îmbunătăți performanța site-ului și de a avea mai mult control și securitate asupra aplicației.

Arhitectura inițială WordPress este monolitică , astfel încât interfața de utilizator și accesul la date sunt combinate pe aceeași platformă.

De la introducerea API-ului REST pe WordPress, acesta poate fi folosit într-un mod fără cap, permițând dezvoltatorilor să îl folosească ca backend și având front-end într-un proiect diferit.

În acest mod decuplat, modelele și controlerele sunt grupate pe partea WordPress , gestionând manipularea datelor și interacțiunea cu bazele de date. Între timp, front-end-ul interacționează doar cu API-ul REST prin intermediul unui client HTTP.

Dar acest lucru are și unele dezavantaje, mai trebuie să configurați și să actualizați WordPress, să îl faceți sigur și sunt dependenți de tehnologia lor pentru dezvoltarea de noi funcționalități.

Lectură similară pe SmashingMag

Pentru cei dintre voi care abia încep în lumea fără cap, aceste articole vă vor ajuta să înțelegeți dezavantajele din spatele ei și de ce toată lumea începe să migreze.

• „CMS fără cap explicat în 5 minute efective”
• „Regândește-ți strategia de conținut pentru un CMS fără cap”
• „Cum gândirea în componente vă poate crește productivitatea”
• O listă organizată de articole legate de „Fără cap” →

Dar de ce să migrați la un CMS fără cap?

Ținând cont de faptul că acest articol va arăta cum să migrați de la WordPress la un CMS Headless, WordPress este probabil configurația dvs. actuală.

Un CMS Headless ne va oferi libertatea de a ne concentra doar pe proiectul front-end , putând alege tehnologia cu care suntem familiarizați și asupra structurii datelor noastre. În final, se ocupă de managementul conținutului și de livrarea conținutului, astfel încât să ne putem ocupa de partea de randare.

„Un CMS Headless este un sistem care oferă aceleași caracteristici ca și un Sistem de management al conținutului (CMS) și multe altele, toate expuse printr-un API.”

Acest tip de configurare este util în special pentru companiile care au mai multe site-uri și doresc să reducă costurile sau să simplifice procesele. O arhitectură fără cap permite acestor companii să centralizeze managementul conținutului într-o singură interfață de administrare , oferind API-urile care vor fi consumate de diferitele pagini web ale companiei.

O altă utilizare comună a unei arhitecturi fără cap este crearea unui proiect front-end care să reprezinte marca companiei. În acest fel, toate produsele pe care compania le lansează vor avea același aspect, dar fiecare va avea propriul conținut, gestionat în același panou de administrare.

Notă : Acest exemplu poate fi văzut cu ușurință pe site-urile web de conferințe precum JSWorld Conference și VueJS Amsterdam care, fiind de la aceiași creatori, proiectul front-end este același, doar conținutul se modifică.

Spre deosebire de un CMS precum WordPress, într-un CMS Headless aveți un panou de administrare deja configurat și întreținut , și uneori și găzduit, pentru dvs. Pentru a începe să creați conținut, trebuie doar să vă creați un cont, să vă conectați și veți putea să creați, editați, duplicați și ștergeți conținutul, gestionați utilizatorii, traduceți conținutul și lucrați cu fluxurile de lucru de publicare, printre altele.

Un CMS fără cap va face mai ușor pentru oamenii din echipa ta să înțeleagă fluxul de lucru, fie că sunt creatori de conținut sau marketeri, lucru de reținut dacă nu ești singurul care va edita conținutul.

Este de remarcat faptul că unele CMS Headless, nu se concentrează doar pe a vă oferi serviciile deja oferite de un CMS precum WordPress. De asemenea, oferă servicii precum CDN-uri pentru imagini pentru a vă redimensiona sau reformata imaginile din mers sau securitate suplimentară prin backup-uri S3.

Având această configurare nu numai că vă va oferi libertate, securitate și confort, dar va îmbunătăți și performanța aplicației dvs. fără servicii terțe. Doar conectându-vă proiectul front-end printr-un client HTTP și obțineți componentele și datele, veți fi în funcțiune.

Beneficiile de a rămâne fără cap și când are sens

Arhitectura WordPress de multe ori nu oferă posibilitățile de care avem nevoie uneori atunci când lucrăm pe un site web, mai ales când vine vorba de optimizarea performanței , unul dintre cele mai importante puncte atunci când ne poziționăm site-ul într-un motor de căutare precum Google și mai ales acum când Web Vitals este sus. și alergând.

Dar este clar că dacă avem un site personal la care lucrăm doar noi înșine, atunci nu este necesar să-l migrăm la o configurație fără cap. Cu toate acestea, dacă mai mulți oameni sunt implicați în acel proiect (nu doar dezvoltatori, ci creatori de conținut sau echipe de marketing), atunci ar trebui să luăm în considerare adoptarea Headless CMS.

Cum ne poate ajuta un CMS headless să îmbunătățim performanța site-ului nostru web și calitatea proiectului nostru front-end?

• Permițându-vă să dezvoltați front-end- ul într-un mod care este complet independent de platforma pe care vă editați conținutul.

  Tehnologia pe care o alegeți este alegerea dvs., dacă doriți să vă actualizați proiectul la cel mai recent framework front-end, nu ați fi dependent de un back-end și ați putea face acest lucru fără a fi nevoie să regândiți migrațiile.

• Permițându-vă să creați proiecte multiplatformă fără a fi nevoie să depindeți de diferite panouri de administrare.

  În cele din urmă, dacă pentru o aplicație aveți nevoie de o descriere mai scurtă decât site-ul web principal, puteți oricând să utilizați un nou câmp „short_description” și să îl reprezentați doar pe front-end-ul acelei aplicații specifice.

• Este destinat să ușureze dezvoltarea și să simplifice procesul de creare a unui site, precum și scalarea acestuia.

  Având front-end-ul complet izolat, putem schimba aspectul vizual al întregii noastre aplicații fără a modifica structura conținutului nostru.

• Oferind mereu servicii care ne vor permite să ne optimizăm activele și viteza de răspuns cu care ni le sunt servite. În cele din urmă, toate datele noastre vor fi livrate prin rețele CDN.

O rețea de livrare de conținut (CDN) este o rețea distribuită geografic de servere proxy și centrele lor de date. Scopul este de a oferi disponibilitate și performanță ridicate prin distribuirea spațială a serviciului în raport cu utilizatorii finali.

„

Ce se întâmplă dacă ne îngrijorează cum va funcționa cu structura mărcii sau a companiei noastre?

• Pe lângă faptul că acceptă aplicații multiplatforme, ne permite, de asemenea, să menținem coerența mărcii .

  Având front-end-ul ca proiect de bază și având mai multe spații într-un CMS Headless, vă permite să aveți consistență între produsele dvs. și face scalabilitatea mai ușoară, deoarece avem mai puțin cod de întreținut.

• Deși nu toate CMS-urile fără cap au acest beneficiu, CMS-ul fără cap spre care migrăm, Storyblok, are un editor vizual, care permite crearea independenței între echipe . Editorii sau creatorii de conținut pot accesa panoul pentru a edita conținutul existent sau pentru a crea conținut nou, putând vedea o previzualizare a modului în care va arăta înainte de publicare. Deci nu vor trebui să implice echipa de dezvoltare în acest proces și își pot face munca mai eficient.

• De asemenea, eficientizează gestionarea conținutului, permițându-vă să vă configurați propriul flux de lucru de conținut . Puteți defini etapele prin care trebuie să parcurgă un conținut înainte de a fi publicat și, abia atunci când trece procesul cu succes, va fi publicat.

Cum poate un CMS fără cap să economisească timp în comparație cu un CMS tradițional?

• Aveți grijă să mențineți securitatea platformei și să o actualizați în numele dvs. Ori de câte ori există o eroare sau utilizatorii necesită o nouă funcție, echipa din spatele CMS-ului tău Headless o va dezvolta pentru tine, trebuie doar să începi să o folosești!
• Îmbunătățirea constantă a experienței utilizatorului (UX) și a designului (UI) pentru dvs., astfel încât creatorii și dezvoltatorii de conținut să se simtă confortabil creând noi câmpuri, componente sau pagini. Dar nu numai la aspectul vizual, ci vor căuta și să îmbunătățească performanța bazei de date, astfel încât să obțineți conținutul instantaneu și să uitați de toată munca care este implicată.

Monolitic vs fără cap

După ce am văzut avantajele pe care o configurare fără cap le poate aduce proiectului nostru și oamenilor care lucrează la el, cred că este timpul să ne uităm la pașii de care avem nevoie pentru a migra proiectul nostru.

De ce trebuie să aveți în vedere când mergeți fără cap

După cum am menționat deja, Headless CMS permite o separare clară a preocupărilor între creatorii de conținut și dezvoltatori. În acest fel (într-un CMS Headless), dezvoltatorul se concentrează pe crearea structurii de conținut, care va fi reprezentată în proiectul front-end, iar editorul se va ocupa de utilizarea componentelor și de completarea acestora cu conținut în panoul de administrare. .

Tip de conținut pe care îl putem crea într-un CMS fără cap

1. Tipuri de intrare sau șablon

Similar cu tipurile de postări personalizate din WordPress, dar cu mai multă libertate și extensibilitate atunci când vine vorba de tipuri de date și editori.

Când creați o nouă intrare de conținut în tabloul de bord, vă așteptați să puteți alege ce tip depinde de situație. De exemplu, dacă aveți un site web cu blog, veți dori să aveți mai multe tipuri de șabloane, unul pentru pagini cu listări sau conținut dinamic numit „ pagină ” și unul pentru fiecare intrare de blog „ post ”.

În funcție de CMS-ul fără cap pe care l-ați ales, numele va varia, dar conceptul este același. În Storyblok, aceste tipuri de entități sunt numite Tip de conținut . „Tipuri de conținut” definesc tipul de intrare de conținut și poate conține câmpurile de bază pentru intrările de conținut. În mod implicit, avem un tip de conținut „Pagină”.

2. Componente reutilizabile

Într-un CMS Headless, puteți crea, pe lângă tipurile de conținut, componente imbricate și le puteți reutiliza între tipurile de conținut și alte componente. În Storyblok, acest tip de componentă - după cum probabil ați observat din numele său - se numește Blok .

Pentru a le utiliza într-un tip de conținut , cum ar fi o pagină, va trebui să creați un câmp în schema blocurilor de tip. Acest câmp vă permite să adăugați componente imbricate la pagina dvs. în timp ce adăugați conținut.

Dar, în principiu, nu vom avea nevoie de astfel de componente în timpul migrării. Pur și simplu vă oferă flexibilitatea de a crea aplicații robuste și dinamice fără a fi nevoie să implicați dezvoltatorul.

De exemplu, atunci când un membru al echipei de marketing dorește să adauge un nou Erou la pagina Despre noi, dacă componenta Hero a fost creată ca imbricată și pagina avea un câmp Blocuri, persoana de marketing ar putea adăuga Erou fără a fi nevoie să implice dezvoltator.

Redarea datelor care provin de la CMS-ul fără cap

Pe măsură ce definim structura conținutului nostru în panoul Headless CMS, trebuie să luăm în considerare cu ce cadru dorim să creăm proiectul nostru front-end și cu ce client HTTP vom folosi.

Atunci când alegem un cadru trebuie să luăm în considerare mai mulți factori:

Echipa mea și cu mine suntem familiarizați cu această tehnologie?

Îmi permite să-mi redau conținutul în tipul de redare de care are nevoie proiectul meu?

Are pluginuri sau module care facilitează integrarea cu CMS-ul Headless pe care îl folosesc?

În cele mai multe cazuri, un site static va fi suficient și va fi întotdeauna cel mai economic și mai performant răspuns. Deci, trebuie doar să căutați un generator de site static pentru tehnologia cu care sunteți familiarizat, de exemplu, Nuxt pentru Vue sau Next pentru biblioteca React.

Conectând aceste două lucruri, un CMS Headless și un generator de site-uri static sunt considerate un set de bune practici de dezvoltare web concentrate pe furnizarea de cea mai înaltă performanță, securitate și cel mai mic cost. Această arhitectură este cunoscută și sub numele de Jamstack. Este o arhitectură concepută pentru a face web-ul mai rapid, mai sigur și mai ușor de scalat. Se bazează pe multe dintre instrumentele și fluxurile de lucru pe care dezvoltatorii le plac și care aduc productivitate maximă.

Folosind cadrele la modă, veți fi asigurat de un ghid de integrare cu CMS-ul Headless cu care veți lucra, iar majoritatea dintre ele au deja un modul sau pachet care vă permite să obțineți informații din API și, în multe cazuri, extinde-l.

Singurul lucru care vă rămâne de făcut este să definiți structura componentelor dvs. privind modul în care ați structurat datele în CMS-ul dvs. Headless și să automatizați procesul de publicare a conținutului. De exemplu, folosind Webhook-urile pe care ți le oferă Headless CMS, vei putea începe un proces de construire în găzduirea ta preferată prin intermediul hook-urilor sale de compilare odată ce conținutul a fost publicat.

Cantitatea de timp de care veți avea nevoie

Ca și în cazul oricărei migrari, timpul necesar va depinde întotdeauna proporțional de complexitatea proiectului dumneavoastră. Dacă vorbim despre un site WordPress obișnuit, va trebui doar să migrați tipurile de Postări pe care le-ați definit sau care vin implicit în acesta, cum ar fi Pagini, Postări și Categorii și conținutul acestora.

Dacă, pe de altă parte, ți-ai personalizat proiectul cu mai multe plugin-uri, va trebui să le dezvolți prin proiectul front-end sau folosind cele furnizate de CMS-ul tău Headless. De exemplu, dacă suntem conștienți de SEO și, prin urmare, folosim Yoast SEO pe WordPress, vom avea pluginul Field-Type SEO în Storyblok pentru a ne ajuta în tranziție, dar va trebui totuși să ne dezvoltăm sitemap-ul în front-end cu un ghid care să ne ajute.

În cele din urmă, toată povara dezvoltării va cădea pe proiectul front-end, deoarece configurarea CMS-ului Headless nu va dura atât de mult timp.

Dar haideți să nu mai vorbim și să aruncăm o privire!

Pași pentru a migra conținutul nostru de la WordPress la Storyblok

Migrarea va consta în patru pași, de la crearea unui spațiu în noul nostru Headless CMS Storyblok până la reprezentarea conținutului migrat în proiectul nostru front-end, pe care îl vom vedea în detaliu mai jos și în care vă voi lăsa resurse pentru ușurează migrația pentru tine.

Să începem!

1. Crearea unui spațiu în Storyblok

Pentru a crea un spațiu în Storyblok, mai întâi trebuie să aveți un cont. Pentru a face acest lucru, va trebui să selectați planul care vi se potrivește cel mai bine.

Accesați pagina Prețuri și începeți cu planul care se potrivește cel mai bine nevoilor dvs. sau încercați planul gratuit pentru testare.

Creează-ți contul și vei putea accesa panoul.

Alegeți „Creați un spațiu nou” și să începem!

Space este un depozit de conținut. Gândiți-vă la el ca la un loc în care să păstrați tot conținutul legat de un singur proiect. Fiecare spațiu are propriile componente, surse de date, active, medii, domenii, colaboratori și permisiuni.

Acordați-vă timp pentru a explora secțiunile din bara laterală din stânga. Începeți prin a căuta următoarele:

• Conținut , acesta va fi folderul în care va fi stocat conținutul, unde echipa de marketing își va petrece cea mai mare parte a timpului.
• Active , unde vor fi stocate toate imaginile, pe care apoi le puteți obține prin serviciul CDN, optimizat și de orice dimensiune.
• Componente , unde veți crea tipurile de conținut și componentele Imbricate .
• Setări , secțiunea în care veți putea configura datele spațiului dvs. precum și limbile aplicației dvs., fluxurile de lucru pe care doriți să le urmeze conținutul înainte de a fi publicat, permisiunile utilizatorilor etc. Să spunem că această zonă va fi unul legat de echipa IT a proiectului.

Dacă tot doriți să explorați fiecare opțiune de pe tabloul de bord înainte de a vă scufunda în migrare, vă recomand să aruncați o privire la Understanding the UI by Storyblok.

Acum că știți puțin despre ecosistemul Storyblok, este timpul să definiți cum va arăta conținutul aplicației noastre.

2. Definirea modelelor

Pentru a migra conținutul WordPress la Storyblok, următorul pas este să creați schemele care definesc structura de date WP prin crearea de tipuri de postări în spațiul Storyblok.

Să începem cu pagini și postări (principalele tipuri de postări din orice site WP), pe care le vom numi page și le vom post în Storyblok.

Schema paginilor din WP conține câmpurile: titlu , slug , imagine prezentată , dată și conținut .

Notă : Pentru a vedea toate câmpurile conținute într-un tip de postare, accesați schema la referințele schemei WP REST API.

Ceea ce trebuie să știți este că, în mod implicit, orice tip de conținut din Storyblok va avea câteva câmpuri deja definite pentru dvs., cum ar fi Nume , Slug , Etichete , Data primei publicate și așa mai departe.

Aceste câmpuri ar putea fi folosite pentru a migra conținutul din WP. Va trebui doar să-l extindeți adăugând featured_image și conținut în Tipul de conținut al paginii.

Accesați secțiunea Componente din spațiul dvs., faceți clic pe page creată implicit, eliminați câmpul de corp și adăugați featured_image ca tip Assets > Images and content ca Rich-text .

Odată ce schema page este gata, să trecem la post . Pentru Tipul de conținut al postării, este necesar să includeți mai multe informații, cum ar fi imaginea_focalizată , extras , conținut și relații cu alte tipuri , cum ar fi Autori sau Categorii .

Deoarece autorii și categoriile vor avea și propriul conținut, accesați secțiunea Conținut din bara laterală și creați câteva foldere numite autori și categorii .

Fiecare dintre foldere trebuie să aibă asociat un tip de conținut implicit. Pentru a face acest lucru, în secțiunea Componente , creați Autor și Categorie ca noi tipuri de conținut, apoi asociați Tipul de conținut relativ la fiecare folder făcând clic pe cele trei puncte din dreapta folderului și selectând Setări.

În acest fel, în Tipul de conținut Post puteți adăuga un câmp Single-Option sau Multi-Options cu Povești sursă și indicați către folderul creat pentru fiecare câmp:

• Autorii
  Aceasta specifică folderul în care se află authors/ .
• Categorii
  Aceasta specifică folderul în care se află categories/ .

Notă : Dacă doriți să aflați mai multe despre această relație, aruncați o privire la articolul Relația dintre autori și articole.

Acum că ați văzut cum să creați câteva tipuri de conținut și cum să creați relații între ele, va trebui să definiți restul modelelor urmând aceiași pași.

Adăugarea unui tip de conținut: global

Și vă întrebați, cum rămâne cu conținutul pe care îl vor împărtăși toate paginile mele? Vă place meniul de navigare, subsolul și alte elemente comune?

Nu vă faceți griji, Storyblok s-a gândit deja la asta și ne oferă un ghid simplu pentru a ne defini dinamic elementele globale. Ne arată cum să creăm un tip de conținut global și cum să îl folosim în secțiunea Conținut .

3. Migrarea Conținutului

Acum este timpul să începeți migrarea conținutului pe care l-ați stocat. Pentru a accesa conținutul WP, trebuie să accesați API-ul REST JSON. Accesați calea /wp-json , dacă proiectul este implementat, sau ?rest_route=/ dacă este local.

În cazul în care niciuna dintre cele două rute nu funcționează, inspectați HTML-ul paginii dvs. pentru un link în cap cu rel="https://api.w.org/" , așa cum este indicat în ghidul de descoperire WP și obțineți-l pe cel corect .

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

Pentru a ne ajuta în timpul migrării, dezvoltatorii Storyblok ne-au oferit un plugin care ne va economisi multă muncă. Acest plugin se numește wordpress-importer, pe el, este posibil să definiți tipul de conținut echivalent în Storyblok pentru tipul WP Post care urmează să fie migrat și îl va împinge în spațiul nostru și va migra imaginile în secțiunea noastră de active pentru noi.

Notă : Utilizarea acestui script necesită un nod ≥14.0.0 deoarece utilizează înlănțuirea opțională.

Crearea scriptului de migrare

Primul lucru de făcut este să clonați depozitul. Apoi, instalați pachetele NPM, folosind npm install sau yarn și creați un fișier în rădăcina proiectului ca migrateWPtoStoryblok.js . Pentru a rula scriptul, aveți nevoie de un script în package.json pentru a-l rula, adăugați:

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

Odată ce totul este gata, este timpul să începeți definirea scriptului urmând specificațiile README. Și, după cum puteți vedea, următorul lucru care va fi necesar este să găsiți Space_id și token-ul OAuth pentru a vă conecta la spațiul Storyblok.

• Space_id se află în secțiunea Setări a barei laterale, de îndată ce dați clic pe el, îl veți vedea în partea dreaptă.
• Pentru a genera OAuth , trebuie să mergeți în partea de sus a barei laterale, să faceți clic pe săgeata mică de lângă sigla Storyblok și să accesați Contul meu . Dacă derulăm în jos, vom vedea secțiunea Jetoane de acces personal , vom genera unul și îl vom copia.

Când ați obținut ambele secrete, le puteți adăuga la începutul scriptului împreună cu adresa URL a API-ului JSON al proiectului dvs.:

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

După cum este descris în secțiunile anterioare, tipul de conținut al paginii din Storyblok este echivalentul tipului de postare din paginile WP. În blocul de cod de mai jos, veți vedea unde va trebui să specificați fiecare.

Și, odată definite tipul de postare și tipul de conținut, este timpul să specificați numele câmpurilor utilizate în acest tip de entitate în WP și numele echivalent în Storyblok, în opțiunea 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" } } ] })

Notă : Pentru ca migrarea să funcționeze corect, asigurați-vă că permalinkurile sunt selectate după numele intrării și nu la fel de simplu. În caz contrar, scriptul nu va crea relația părinte-copil între pagini.

În schema_mapping puteți defini mai multe tipuri de câmpuri, acestea pot fi:

• Un câmp simplu , cum ar fi title .
• O subproprietate a unui câmp, cum ar fi în acest caz adresa URL a imaginii caracteristice.
  Notă : pluginul în sine se ocupă de migrarea imaginilor în spațiul Storyblok prin adresa URL asociată în links.wp:featuredmedia.0 .

• Un câmp a migrat la un bloc imbricat în Storyblok.

  Imaginați-vă că doriți să creați o componentă în Storyblok pentru a defini textul bogat al site-ului dvs., astfel încât toate tipurile de postări care îl folosesc să aibă același stil și aceleași opțiuni.

  Pentru aceasta, puteți utiliza formatul obiectului și puteți specifica numele câmpului în modelul Storyblok sub proprietatea câmpului , numele componentei pe care doriți să o stocați în acel câmp și numele câmpului din interiorul componentei în care se află conținutul. vor fi migrate.

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

Pagina de tip de intrare

Acum că știți cum să definiți tipurile de câmpuri, pentru schema paginii, ar arăta ca în blocul de cod de mai jos.

Pluginul se va ocupa de relația părinte-copil dintre pagini prin crearea unui folder în Storyblok sub slug-ul părintelui și asociind părintele ca acasă a acelui folder.

În plus, dacă câmpul de conținut conține imagini , pluginul îl va migra și pentru tine!

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

Tip de intrare Post

Postările au o schemă asemănătoare paginilor, dar, în acest caz, pentru a le stoca într-un folder trebuie să definiți numele folderului sub tipul de intrare:

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

Categoria de tip de intrare

Și odată ce schema pentru postări a fost definită, este logic să definiți schema pentru categorii, astfel încât acestea să poată fi asociate așa cum este descris în secțiunea anterioară.

Pentru a defini folderul care le conține ca categorii și nu ca categorie, numele lor implicit, trebuie să mergeți la opțiunea Permalink -uri din adminul WordPress și să schimbați opțiunea de bază Categorii la categories . Atunci câmpul multi-opțiune al intrărilor Post va fi cel care are relația cu categoriile corespunzătoare.

Notă : Acești pași sunt aceiași cu cei care trebuie urmați pentru migrarea autorilor și legarea acestora la articole.

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

Scenariul final complet

Codul de mai jos va fi scriptul de migrare rezultat dintr-un proiect WP cu tipurile de bază în spațiul Storyblok pe care l-am creat.

 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ți un proiect front-end

Acum că conținutul este deja stocat în tabloul de bord Storyblok, este timpul să conectați proiectul Front-end la Storyblok.

Oricare ar fi cadrul sau biblioteca dvs. JS, Storyblok oferă clientul JavaScript care vă va ajuta cu integrarea. În plus, în cazul în care utilizați un anumit cadru, veți găsi și alte pachete care vă vor ușura drumul, cum ar fi în Nuxt modulul storyblok-nuxt .

Acest API JavaScript va include, de asemenea, o punte între Storyblok și aplicația dvs. Front-end. Puntea este responsabilă pentru comunicarea prin iframe cu Storyblok pentru a spune interfeței de editare ce componentă să deschidă atunci când utilizatorul face clic pe ea.

Iată o listă de tutoriale pe care le puteți găsi pe Storyblok pentru a vă conecta proiectul Front-end.

Notă : Dacă nu găsești tehnologia ta printre ele, nu-ți face griji există multe alte tutoriale pe site-ul Storyblok, caută-l pe a ta în motorul de căutare, iar dacă nu găsești una te încurajez să-i contactezi, si vei ajuta mult mai multi oameni!

• Următorul
• Gatsby
• Vue
• Nuxt
• unghiular
• Svelt
• Ember
• AMP

5. Găzduiește-ți proiectul front-end și automatizează implementarea

Odată ce proiectul dvs. este gata să intre în producție, alegeți un furnizor de găzduire și vă conectați depozitul pentru o implementare ușoară, apoi vă întrebați:

Cum îmi redistribui site-ul static dacă public o intrare pe Storyblok?

Răspunsul este foarte simplu: folosind webhook-urile oferite de Storyblok și build-urile de găzduire.

Pentru a vă oferi un exemplu real, puteți crea URL-uri de build hooks în Netlify în secțiunea de implementare; URL-ul creat pentru Storyblok în build hooks va merge în câmpul Setări → Webhooks → Povestea publicată și nepublicată din spațiul Storyblok.

Ghiduri și instrumente pe care le-am folosit în timpul migrației

Să recapitulăm link-urile care au ajutat la migrarea conținutului și cele care au ajutat la înțelegerea funcționării API-ului REST și a CMS-ului fără cap către care migrați.

Este necesară documentația API-ului WP REST

API-ul REST

• Referință la punctul final pentru dezvoltatori API REST
• Folosind API-ul REST
• Descoperirea API-ului și a traseului acestuia

Scheme

• Referința schemei paginii
• Postați referința la schemă
• Referință schema categoriilor

Migrarea la Storyblok

Informatii generale

• Site-ul oficial Storyblok
• Prețuri și planuri Storyblok

Documentație

• Înțelegerea interfeței de utilizare
• Structuri de Conținut
• Configurarea structurii conținutului blogului în Storyblok

Componente globale

• Cum să construiți o navigare în meniul antetului site-ului cu Storyblok
• Podul Storyblok V2

Legat de SEO

• Cum se generează sitemap a445r cu un CMS fără cap?
• https://www.storyblok.com/apps/seo

Webhooks și Build Hooks

• Totul despre Webhooks
• Cum să utilizați webhook-urile Storyblok
• Găzduire build hooks - exemplu Netlify

Scripturi și pachete

• SDK universal JavaScript pentru API-ul Storyblok: https://github.com/storyblok/storyblok-js-client
• Asistentul de migrare WP la Storyblok: https://github.com/storyblok/wordpress-importer

Jamstack

• Site-ul web Jamstack
• O listă de generatoare de site statice pentru site-urile Jamstack

Concluzie

După ce ați citit acest articol, veți avea ceea ce aveți nevoie pentru a înțelege de ce o configurare fără cap vă va îmbunătăți proiectul, cum să migrați de la proiectul dvs. WordPress la un CMS fără cap precum Storyblok și cum să continuați să vă îmbunătățiți și să vă extindeți proiectul.

După cum ați văzut, posibilitățile unei configurații fără cap sunt nesfârșite . 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?