Jak przejść z WordPressa do bezgłowego CMS
Opublikowany: 2022-03-10Ten artykuł został uprzejmie wsparty przez naszych drogich przyjaciół ze Storyblok, przyjaznego bezgłowego CMS z edytorem wizualnym, zagnieżdżonymi komponentami i dostosowywanymi blokami treści dla stron internetowych i aplikacji. Dziękuję Ci!
WordPress to najczęściej używany kreator stron internetowych na świecie; prawie połowa sieci wykorzystała WordPress do stworzenia swojej strony internetowej. Ma to sens, ponieważ pozwala szybko tworzyć strony internetowe i ma bogaty ekosystem wtyczek, które pomagają skalować witrynę.
Ale technologia ewoluuje i pojawia się coraz więcej opcji ułatwiających tworzenie stron internetowych. Ponadto dają nam możliwość poprawienia wydajności strony oraz większej kontroli i bezpieczeństwa nad aplikacją.
Początkowa architektura WordPressa jest monolityczna , więc interfejs użytkownika i dostęp do danych są połączone na tej samej platformie.
Od czasu wprowadzenia interfejsu API REST na WordPress, można go używać w sposób bezgłowy, pozwalając programistom na używanie go jako zaplecza i posiadanie frontonu w innym projekcie.
W ten sposób oddzielone modele i kontrolery są połączone po stronie WordPressa , obsługując manipulację danymi i interakcję z bazą danych. Tymczasem front-end współdziała tylko z interfejsem API REST za pośrednictwem klienta HTTP.
Ale ma to również pewne wady, nadal trzeba konfigurować i aktualizować WordPressa, zabezpieczać go i być zależnym od ich technologii w celu tworzenia nowych funkcjonalności.
Powiązane czytanie na SmashingMag
Tym z was, którzy dopiero zaczynają przygodę z bezgłowym światem, te artykuły pomogą zrozumieć tajniki tego i dlaczego wszyscy zaczynają migrować.
- „Bezgłowy CMS wyjaśniony w 5 efektywnych minut”
- „Przemyśl swoją strategię treści dla bezgłowego CMS”
- „Jak myślenie o komponentach może zwiększyć Twoją produktywność”
- Wyselekcjonowana lista artykułów związanych z „Headless” →
Ale po co migrować do CMS bez głowy?
Biorąc pod uwagę, że ten artykuł pokaże, jak przeprowadzić migrację z WordPressa do Headless CMS, WordPress jest prawdopodobnie twoją obecną konfiguracją.
Headless CMS da nam swobodę skupienia się tylko na projekcie front-endowym , wybierając technologię, którą znamy, oraz strukturę naszych danych. W końcu zajmuje się zarządzaniem treścią i dostarczaniem treści, dzięki czemu możemy zająć się częścią renderującą.
„Headless CMS to system, który zapewnia te same funkcje, co system zarządzania treścią (CMS) i nie tylko, wszystkie udostępniane za pośrednictwem interfejsu API”.
Ten rodzaj konfiguracji jest szczególnie przydatny dla firm, które mają wiele lokalizacji i chcą obniżyć koszty lub uprościć procesy. Bezgłowa architektura umożliwia tym firmom scentralizowanie zarządzania treścią w jednym interfejsie administracyjnym , udostępniając interfejsy API, które będą używane przez różne strony internetowe firmy.
Innym powszechnym zastosowaniem architektury bezgłowej jest stworzenie projektu front-end, który reprezentuje markę firmy. W ten sposób wszystkie produkty, które firma wprowadza na rynek, będą miały ten sam wygląd i działanie, ale każdy z nich będzie miał własną treść, zarządzaną w tym samym panelu administracyjnym.
Uwaga : ten przykład można łatwo zobaczyć na stronach konferencji, takich jak JSWorld Conference i VueJS Amsterdam, które pochodzą od tych samych twórców, a projekt front-endowy jest taki sam, zmienia się tylko treść.
W przeciwieństwie do CMS, takiego jak WordPress, w Headless CMS masz już skonfigurowany i utrzymywany panel administracyjny , a czasem także hostowany dla Ciebie. Aby rozpocząć tworzenie treści, wystarczy założyć konto, zalogować się, a będziesz mógł między innymi tworzyć, edytować, duplikować i usuwać swoje treści, zarządzać użytkownikami, tłumaczyć treści i pracować z obiegami publikacji.
Bezgłowy CMS ułatwi ludziom w Twoim zespole zrozumienie przepływu pracy, niezależnie od tego, czy są to twórcy treści, czy marketerzy, o czym należy pamiętać, jeśli nie jesteś jedyną osobą, która będzie edytować treść.
Warto zauważyć, że niektóre CMS typu Headless nie skupiają się tylko na oferowaniu usług już oferowanych przez CMS, taki jak WordPress. Zapewnia również usługi, takie jak sieci CDN obrazów, umożliwiające zmianę rozmiaru lub formatowanie obrazów w locie, lub dodatkowe zabezpieczenia dzięki kopiom zapasowym S3.
Taka konfiguracja nie tylko zapewni Ci swobodę, bezpieczeństwo i wygodę, ale także poprawi wydajność Twojej aplikacji bez usług stron trzecich. Wystarczy połączyć swój projekt front-end za pośrednictwem klienta HTTP i pobrać komponenty i dane, aby móc działać.
Korzyści z chodzenia bez głowy i kiedy to ma sens
Architektura WordPressa często nie oferuje możliwości, których czasami potrzebujemy podczas pracy na stronie internetowej, zwłaszcza jeśli chodzi o optymalizację wydajności , jeden z najważniejszych punktów przy pozycjonowaniu naszej strony w wyszukiwarce takiej jak Google, a zwłaszcza teraz, gdy Web Vitals jest na górze i bieganie.
Ale jasne jest, że jeśli mamy osobistą witrynę, nad którą pracujemy tylko my sami, nie ma potrzeby migracji jej do konfiguracji bezgłowej. Jeśli jednak w ten projekt zaangażowanych jest więcej osób (nie tylko programiści, ale twórcy treści czy zespoły marketingowe), powinniśmy rozważyć zastosowanie Headless CMS.
W jaki sposób bezgłowy CMS może nam pomóc poprawić wydajność naszej strony internetowej i jakość naszego projektu front-end?
Pozwalając na rozwijanie front-endu w sposób całkowicie niezależny od platformy, na której edytujesz swoje treści.
Wybrana technologia jest Twoim własnym wyborem , jeśli chciałbyś zaktualizować swój projekt do najnowszego frameworka front-end, nie byłbyś zależny od back-endu i mógłbyś to zrobić bez konieczności ponownego przemyślenia migracji.
Umożliwia tworzenie projektów wieloplatformowych bez konieczności polegania na różnych panelach administracyjnych.
W końcu, jeśli dla aplikacji potrzebujesz krótszego opisu niż główna strona internetowa, zawsze możesz skorzystać z nowego pola „short_description” i po prostu przedstawić go na interfejsie tej konkretnej aplikacji.
Ma on na celu ułatwienie rozwoju i uproszczenie procesu tworzenia witryny, a także jej skalowania.
Dzięki całkowitemu wyizolowaniu front-endu możemy zmienić wygląd całej naszej aplikacji bez modyfikowania struktury naszych treści.
Zawsze oferując usługi, które pozwolą nam zoptymalizować nasze aktywa i szybkość reakcji , z jaką są nam podawane. Docelowo wszystkie nasze dane będą dostarczane przez sieci CDN.
Sieć dostarczania treści (CDN) to geograficznie rozproszona sieć serwerów proxy i ich centrów danych. Celem jest zapewnienie wysokiej dostępności i wydajności poprzez przestrzenne rozmieszczenie usługi względem użytkowników końcowych.
“
A co, jeśli martwi nas, jak będzie działać ze strukturą naszej marki lub firmy?
Oprócz obsługi aplikacji wieloplatformowych pozwala nam również zachować spójność marki .
Posiadanie front-endu jako projektu bazowego i posiadanie wielu spacji w Headless CMS pozwala zachować spójność między produktami i ułatwia skalowalność, ponieważ mamy mniej kodu do utrzymania.
Chociaż nie wszystkie headless CMS mają tę zaletę, Storyblok, bezgłowy CMS, do którego migrujemy, ma Edytor Wizualny, który umożliwia tworzenie niezależności między zespołami . Redaktorzy lub twórcy treści mogą uzyskać dostęp do panelu, aby edytować istniejące treści lub tworzyć nowe treści, mając możliwość zobaczenia podglądu tego, jak będzie wyglądać przed publikacją. Dzięki temu nie będą musieli angażować zespołu programistów w ten proces i będą mogli wykonywać swoją pracę wydajniej.
Usprawnia również zarządzanie treścią, umożliwiając skonfigurowanie własnego obiegu treści . Możesz zdefiniować etapy, przez które musi przejść treść przed opublikowaniem i dopiero po pomyślnym przejściu procesu zostanie opublikowana.
Jak bezgłowy CMS może zaoszczędzić czas w porównaniu z tradycyjnym CMS?
- Dbanie o utrzymanie bezpieczeństwa platformy i aktualizowanie jej w Twoim imieniu. Ilekroć pojawi się błąd lub użytkownicy będą potrzebować nowej funkcji, zespół odpowiedzialny za Twój Headless CMS opracuje ją dla Ciebie, po prostu musisz zacząć z niej korzystać!
- Ciągle ulepszamy dla Ciebie doświadczenie użytkownika (UX) i projekt (UI), aby twórcy treści i programiści czuli się komfortowo tworząc nowe pola, komponenty lub strony. Ale nie tylko w aspekcie wizualnym, ale także będą dążyć do poprawy wydajności bazy danych, dzięki czemu natychmiast otrzymasz treść i zapomnisz o całej pracy, która jest z tym związana.
Monolityczny kontra Bezgłowy
Funkcja | Monolityczny | Bezgłowy |
---|---|---|
Architektura | Połączone: połączony front-end back-end | Oddzielone: niezależny projekt front-end |
Technologia | Będziesz musiał skorzystać z tego, w którym projekt jest rozwijany | Swoboda wyboru technologii front-end |
Wieloplatformowy | Ograniczony do jednego interfejsu użytkownika na raz | Łączy się z dowolnymi projektami front-end |
Przepływ treści | Ograniczający | Zwyczaj |
Bezpieczeństwo i aktualizacje | Trzymaj się | Troszczy się o Ciebie |
Widząc korzyści, jakie bezgłowa konfiguracja może wnieść do naszego projektu i ludzi, którzy nad nim pracują, myślę, że nadszedł czas, aby przyjrzeć się krokom, które musimy wykonać, aby przeprowadzić migrację naszego projektu.
O czym musisz pamiętać, gdy jedziesz bez głowy
Jak już wspomnieliśmy, Headless CMS pozwala na wyraźne oddzielenie obaw między twórcami treści a programistami. W ten sposób (w Headless CMS) deweloper skupia się na stworzeniu struktury treści, która będzie reprezentowana w projekcie front-endowym, a redaktor będzie odpowiedzialny za wykorzystanie komponentów i wypełnienie ich treścią w panelu administracyjnym .
Rodzaj treści, które możemy stworzyć w bezgłowym CMS
1. Rodzaje wpisu lub szablonu
Podobny do niestandardowych typów postów w WordPress, ale z większą swobodą i rozszerzalnością, jeśli chodzi o typy danych i edytory.
Kiedy idziesz do tworzenia nowego wpisu treści na pulpicie nawigacyjnym, oczekujesz, że będziesz w stanie wybrać typ, który zależy od sytuacji. Na przykład, jeśli masz witrynę internetową z blogiem, będziesz potrzebować kilku rodzajów szablonów, jeden dla stron z wykazami lub dynamiczną zawartością o nazwie „ strona ” i jeden dla każdego wpisu w blogu „ post ”.
W zależności od wybranego CMS-a bez głowy, nazwa będzie się różnić, ale koncepcja jest taka sama. W Storyblok tego typu encje są nazywane Content Type . „Typy treści” definiują typ wpisu treści i mogą zawierać podstawowe pola dla wpisów treści. Domyślnie mamy typ treści „Strona”.
2. Komponenty wielokrotnego użytku
W systemie Headless CMS możesz tworzyć, oprócz typów treści, zagnieżdżone komponenty i wykorzystywać je ponownie między typami treści i innymi komponentami. W Storyblok ten typ komponentu — jak można zauważyć po jego nazwie — nazywa się Blok .
Aby użyć ich w typie zawartości , takim jak strona, musisz utworzyć pole w schemacie bloków typu. To pole umożliwia dodawanie do strony zagnieżdżonych komponentów podczas dodawania treści.
Ale w zasadzie nie będziemy potrzebować takich komponentów podczas migracji. Daje po prostu elastyczność w tworzeniu solidnych i dynamicznych aplikacji bez konieczności angażowania programisty.
Na przykład, gdy członek zespołu marketingowego chce dodać nowego Bohatera do strony O nas, jeśli składnik Bohater został utworzony jako zagnieżdżony, a strona zawierała pole Bloki, osoba zajmująca się marketingiem może dodać Bohatera bez konieczności angażowania deweloper.
Renderowanie danych pochodzących z bezgłowego CMS
Definiując strukturę naszych treści w panelu Headless CMS, musimy zastanowić się z jakim frameworkiem chcemy stworzyć nasz projekt front-endowy i z jakiego klienta HTTP będziemy korzystać.
Wybierając framework musimy wziąć pod uwagę kilka czynników:
Czy mój zespół i ja znam tę technologię?
Czy pozwala mi to renderować moją zawartość w typie renderowania, którego potrzebuje mój projekt?
Czy posiada wtyczki lub moduły ułatwiające integrację z używanym przeze mnie Headless CMS?
W większości przypadków witryna statyczna będzie wystarczająca i zawsze będzie najbardziej ekonomiczną i wydajną odpowiedzią. Musisz więc po prostu poszukać statycznego generatora witryn dla technologii, którą znasz, na przykład Nuxt dla Vue lub Next dla biblioteki React.
Łącząc te dwie rzeczy, Headless CMS i statyczny kreator witryn są uważane za zestaw najlepszych praktyk w zakresie tworzenia stron internetowych, skoncentrowanych na zapewnieniu najwyższej wydajności, bezpieczeństwa i najniższych kosztów. Ta architektura jest również znana jako Jamstack. Jest to architektura zaprojektowana, aby sieć była szybsza, bezpieczniejsza i łatwiejsza do skalowania. Opiera się na wielu narzędziach i przepływach pracy, które uwielbiają programiści i które zapewniają maksymalną wydajność.
Korzystając z modnych frameworków, będziesz mieć pewność, że znajdziesz przewodnik po integracji z Headless CMS, z którym będziesz pracować, a większość z nich ma już moduł lub pakiet, który pozwala na pozyskiwanie informacji z API, a w wielu przypadkach przedłuż go.
Jedyne, co pozostaje Ci do zrobienia, to zdefiniowanie struktury Twoich komponentów dotyczących struktury danych w Twoim Headless CMS i zautomatyzowanie procesu publikowania treści. Na przykład, korzystając z Webhooków, które zapewnia Headless CMS, będziesz mógł rozpocząć proces kompilacji na swoim ulubionym hostingu za pomocą jego haków kompilacji po opublikowaniu treści.
Ilość czasu, której będziesz potrzebować
Jak w przypadku każdej migracji, wymagany czas zawsze będzie zależał proporcjonalnie od złożoności projektu. Jeśli mówimy o popularnej witrynie WordPress, będziesz musiał przeprowadzić migrację tylko zdefiniowanych przez Ciebie typów postów lub znajdujących się w niej domyślnie, takich jak strony, posty i kategorie, oraz ich zawartości.
Jeśli z drugiej strony dostosowałeś swój projekt za pomocą wielu wtyczek, będziesz musiał je opracować za pomocą projektu front-endowego lub korzystając z tych dostarczonych przez Twój Headless CMS. Na przykład, jeśli jesteśmy świadomi SEO i dlatego korzystamy z Yoast SEO na WordPressie, będziemy mieli wtyczkę Field-Type SEO w Storyblok, aby pomóc nam w przejściu, ale nadal będziemy musieli rozwijać naszą mapę witryny w interfejsie z przewodnikiem, który nam pomoże.
Ostatecznie cały ciężar rozwoju spadnie na projekt front-endowy, ponieważ konfiguracja Headless CMS nie zajmie tak dużo czasu.
Ale przestańmy mówić i spójrzmy na to!
Kroki migracji naszych treści z WordPressa do Storyblok
Migracja będzie się składać z czterech kroków, od stworzenia przestrzeni w naszym nowym Storybloku Headless CMS do reprezentacji migrowanych treści w naszym projekcie front-endowym, który szczegółowo zobaczymy poniżej i w którym pozostawię Ci zasoby do ułatwić Ci migrację.
Zacznijmy!
1. Tworzenie przestrzeni w Storyblok
Aby stworzyć przestrzeń w Storyblok, musisz najpierw posiadać konto. Aby to zrobić, musisz wybrać plan, który najbardziej Ci odpowiada.
Przejdź do strony Cennik i zacznij od planu, który najlepiej odpowiada Twoim potrzebom lub wypróbuj darmowy plan do testowania.
Załóż konto, a uzyskasz dostęp do panelu.
Wybierz „Utwórz nową przestrzeń” i zacznijmy!
Space to repozytorium treści. Pomyśl o tym jako o miejscu do przechowywania wszystkich treści związanych z jednym projektem. Każda przestrzeń ma swoje własne komponenty, źródła danych, zasoby, środowiska, domeny, współpracowników i uprawnienia.
Poświęć trochę czasu na zapoznanie się z sekcjami na lewym pasku bocznym. Zacznij od przeglądania następujących informacji:
- Treść , będzie to folder, w którym będą przechowywane treści, w którym zespół marketingowy będzie spędzał większość czasu.
- Zasoby , w których będą przechowywane wszystkie obrazy, które można następnie uzyskać za pośrednictwem usługi CDN, zoptymalizowane i o dowolnym rozmiarze.
- Komponenty , gdzie utworzysz typy zawartości i komponenty zagnieżdżone .
- Ustawienia , sekcja, w której będziesz mógł skonfigurować dane swojej przestrzeni, a także języki Twojej aplikacji, przepływy pracy, które chcesz, aby Twoje treści podążały przed opublikowaniem, uprawnienia użytkownika itp. Załóżmy, że ten obszar będzie jeden związany z zespołem IT projektu.
Jeśli nadal chcesz poznać każdą opcję na desce rozdzielczej przed przystąpieniem do migracji, polecam zajrzeć do Understanding the UI autorstwa Storyblok.
Skoro już wiesz trochę o ekosystemie Storyblok, czas określić, jak będzie wyglądać zawartość naszej aplikacji.
2. Definiowanie modeli
Aby przenieść zawartość WordPressa do Storyblok, kolejnym krokiem jest utworzenie schematów definiujących strukturę danych WP poprzez utworzenie typów postów w przestrzeni Storyblok.
Zacznijmy od stron i postów (główne typy postów w każdej witrynie WP), które nazwiemy page
i post
w Storyblok.
Schemat stron w WP zawiera pola: tytuł , ślimak , wyróżniony obraz , data i treść .
Uwaga : Aby zobaczyć wszystkie pola zawarte w typie postu, przejdź do schematu w Odniesieniach do schematu WP REST API.
Musisz wiedzieć, że domyślnie każdy typ zawartości w Storyblok będzie miał już zdefiniowane pola, takie jak Nazwa , Slug , Tagi , Data pierwszej publikacji i tak dalej.
Te pola mogą być wykorzystane do migracji treści z WP. Wystarczy go rozszerzyć, dodając polecony_obraz i zawartość w typie zawartości strony.
Przejdź do sekcji Komponenty w swoim obszarze, kliknij page
utworzoną domyślnie, usuń pole treści i dodaj polecany_obraz jako typ Assets > Images
i treść jako Rich-text
.
Gdy schemat page
będzie gotowy, przejdźmy do post
. W przypadku typu treści posta konieczne jest podanie dodatkowych informacji, takich jak polecany_obraz , fragment , treść i powiązania z innymi typami , takimi jak autorzy lub kategorie .
Ponieważ Autorzy i Kategorie również będą miały własną treść, przejdź do sekcji Treść na pasku bocznym i utwórz kilka folderów zwanych autorami i kategoriami .
Każdy z folderów musi mieć skojarzony domyślny typ zawartości. Aby to zrobić, w sekcji Komponenty utwórz autora i kategorię jako nowe typy zawartości, a następnie skojarz typ zawartości względem każdego folderu, klikając trzy kropki po prawej stronie folderu i wybierając opcję Ustawienia.
W ten sposób w polu Post Content Type możesz dodać pole Single-Option lub Multi-Options ze źródłowymi historiami i wskazać folder utworzony dla każdego pola:
- Autorski
Określa folder, w którym znajdują sięauthors/
. - Kategorie
Określa folder, w którym znajdują sięcategories/
.
Uwaga : jeśli chcesz dowiedzieć się więcej o tej relacji, zapoznaj się z artykułem Autorzy i relacje między artykułami.
Teraz, gdy już wiesz, jak utworzyć kilka typów treści i jak tworzyć relacje między nimi, będziesz musiał zdefiniować pozostałe modele, wykonując te same kroki.
Dodawanie typu zawartości: Globalne
I zadajesz sobie pytanie, co z treścią, którą będą udostępniać wszystkie moje strony? Podoba Ci się menu nawigacyjne, stopka i inne wspólne elementy?
Nie martw się, Storyblok już o tym pomyślał i oferuje prosty przewodnik do dynamicznego definiowania naszych globalnych elementów. Pokazuje nam, jak utworzyć globalny typ treści i jak go używać w sekcji Treść .
3. Migracja treści
Teraz nadszedł czas, aby rozpocząć migrację zapisanej zawartości. Aby uzyskać dostęp do treści WP, musisz uzyskać dostęp do interfejsu API REST JSON. Uzyskaj dostęp do ścieżki /wp-json
, jeśli projekt jest wdrożony, lub ?rest_route=/
, jeśli jest lokalny.
Jeśli żadna z tych dwóch tras nie działa, sprawdź kod HTML swojej strony pod kątem linku w nagłówku z rel="https://api.w.org/"
, jak wskazano w przewodniku wykrywania WP, i uzyskaj poprawny .
<link rel="https://api.w.org/" href="https://localhost/your-site/index.php?rest_route=/">
Aby pomóc nam podczas migracji, twórcy Storyblok udostępnili nam wtyczkę, która zaoszczędzi nam wiele pracy. Wtyczka ta nazywa się wordpress-importer, w niej można zdefiniować odpowiednik Content Type w Storyblok dla typu WP Post, który ma zostać zmigrowany, a następnie wypchnie go do naszej przestrzeni i przeniesie obrazy do naszej sekcji Zasoby .
Uwaga : Użycie tego skryptu wymaga węzła ≥14.0.0, ponieważ używa on opcjonalnego łączenia w łańcuch.
Tworzenie skryptu migracji
Pierwszą rzeczą do zrobienia jest sklonowanie repozytorium. Następnie zainstaluj pakiety NPM, używając npm install
lub yarn
, i utwórz plik w katalogu głównym projektu jako migrateWPtoStoryblok.js . Aby uruchomić skrypt potrzebujesz skryptu w package.json do jego uruchomienia, dodaj:
"migrate": "node ./migrateWPtoStoryblok.js"
Gdy wszystko będzie gotowe, czas zacząć definiować skrypt zgodnie ze specyfikacją README. Jak widać, następną rzeczą, która będzie potrzebna, jest znalezienie Space_id
i tokena OAuth
, aby połączyć się z przestrzenią Storyblok.
-
Space_id
znajduje się w sekcji Ustawienia na pasku bocznym, gdy tylko go klikniesz, zobaczysz go po prawej stronie. - Aby wygenerować token
OAuth
, musisz przejść na górę paska bocznego, kliknąć małą strzałkę obok logo Storyblok i przejść do Moje konto . Jeśli przewiniemy w dół, zobaczymy sekcję Osobiste tokeny dostępu , wygenerujemy jeden i skopiujemy.
Gdy zdobędziesz oba sekrety, możesz dodać je na początku skryptu wraz z adresem URL API JSON Twojego projektu:
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 })
Jak opisano w poprzednich sekcjach, typ zawartości strony w Storyblok jest odpowiednikiem typu postu na stronach WP . W poniższym bloku kodu zobaczysz, gdzie należy je określić.
A po zdefiniowaniu Post Type i Content Type, nadszedł czas, aby określić nazwę pól używanych w tym typie encji w WP i równoważną nazwę w Storyblok, w opcji 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" } } ] })
Uwaga : aby migracja działała poprawnie, upewnij się, że permalinki są wybrane według nazwy wpisu, a nie tak proste. W przeciwnym razie skrypt nie utworzy relacji rodzic-dziecko między stronami.
W schema_mapping
możesz zdefiniować kilka typów pól, mogą to być:
- Proste pole, takie jak
title
. - Właściwość podrzędna pola, taka jak w tym przypadku adres URL obrazu funkcji.
Uwaga : Sama wtyczka zajmuje się migracją obrazów do przestrzeni Storyblok za pośrednictwem powiązanego adresu URL wlinks.wp:featuredmedia.0
. Pole migrowane do zagnieżdżonego bloku w Storybloku.
Wyobraź sobie, że chcesz utworzyć w Storyblok komponent definiujący tekst sformatowany w witrynie, tak aby wszystkie typy postów, które go używają, miały ten sam styl i opcje.
W tym celu można użyć formatu obiektu i podać nazwę pola w modelu Storyblok pod właściwością pola , nazwę komponentu , który chcemy przechowywać wewnątrz tego pola, oraz nazwę pola wewnątrz komponentu , w którym zawartość zostaną przeniesione.
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()
Strona typu wpisu
Teraz, gdy wiesz, jak zdefiniować typy pól, dla schematu strony wyglądałoby to tak, jak w poniższym bloku kodu.
Wtyczka zajmie się relacjami rodzic-dziecko między stronami, tworząc folder w Storyblok pod ślimakiem rodzica i kojarząc rodzica jako dom tego folderu.
Co więcej, jeśli pole treści zawiera obrazy , wtyczka również je zmigruje!
{ 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", } }
Typ wpisu Post
Posty mają schemat podobny do stron, ale w tym przypadku, aby przechowywać je w folderze, musisz zdefiniować nazwę folderu poniżej typu wpisu:
{ 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", } }
Kategoria typu wpisu
A po zdefiniowaniu schematu dla postów sensowne jest zdefiniowanie schematu dla kategorii, aby można je było powiązać zgodnie z opisem w poprzedniej sekcji.
Aby zdefiniować folder , który je zawiera jako kategorie , a nie jako kategorię, ich domyślną nazwę, musisz przejść do opcji Permalinki w panelu administracyjnym WordPressa i zmienić opcję Baza kategorii na categories
. Wtedy pole z wieloma opcjami wpisów Post będzie tym, które ma związek z odpowiednimi kategoriami.
Uwaga : te kroki są takie same, jak w przypadku migracji autorów i łączenia ich z artykułami.
{ 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", } }
Pełny skrypt końcowy
Poniższy kod będzie wynikowym skryptem migracji z projektu WP z podstawowymi typami do stworzonej przez nas przestrzeni Storyblok.
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. Utwórz projekt front-end
Teraz, gdy zawartość jest już przechowywana w desce rozdzielczej Storyblok, nadszedł czas, aby połączyć projekt Front-end ze Storyblok.
Niezależnie od tego, jaki masz framework lub bibliotekę JS, Storyblok zapewnia klienta JavaScript, który pomoże Ci w integracji. Dodatkowo, jeśli używasz konkretnego frameworka, znajdziesz inne pakiety, które ułatwią Ci drogę, jak w Nuxt moduł storyblok-nuxt
.
Ten JavaScript API będzie również zawierał pomost między Storyblok a Twoją aplikacją front-endową. Most jest odpowiedzialny za komunikację poprzez iframe ze Storyblokem, aby poinformować interfejs edycyjny, który komponent ma zostać otwarty, gdy użytkownik na niego kliknie.
Oto lista samouczków, które możesz znaleźć na Storyblok, aby połączyć swój projekt Front-end.
Uwaga : Jeśli nie znajdziesz wśród nich swojej technologii, nie martw się, na stronie Storyblok jest wiele innych samouczków, poszukaj swojej w wyszukiwarce, a jeśli nie znajdziesz, zachęcam do kontaktu z nimi, a pomożesz wielu innym osobom!
- Następny
- Gatsby
- Vue
- Nuxt
- Kątowy
- Smukły
- Niedopałek
- AMP
5. Hostuj swój projekt front-endowy i zautomatyzuj wdrażanie
Gdy projekt jest gotowy do wdrożenia w środowisku produkcyjnym, wybierasz dostawcę hostingu i łączysz swoje repozytorium w celu łatwego wdrożenia, a następnie zadajesz sobie pytanie:
Jak ponownie uruchomić witrynę statyczną, jeśli opublikuję wpis na Storyblok?
Odpowiedź jest bardzo prosta: za pomocą webhooków oferowanych przez Storyblok i buildów twojego hostingu.
Aby dać ci prawdziwy przykład, możesz utworzyć adresy URL kompilacji haków w Netlify w sekcji wdrażania; URL utworzony dla Storybloka w hakach kompilacji zostanie umieszczony w polu Ustawienia → Webhooki → Historia opublikowana i nieopublikowana w przestrzeni Storyblok.
Przewodniki i narzędzia, z których korzystaliśmy podczas migracji
Podsumujmy linki, które pomogły w migracji treści oraz te, które pomogły zrozumieć działanie REST API i bezgłowego CMS, do którego migrujesz.
Wymagana dokumentacja WP REST API
REST API
- Dokumentacja punktu końcowego programisty interfejsu API REST
- Korzystanie z REST API
- Odkrywanie API i jego trasy
Schematy
- Odniesienie do schematu strony
- Publikuj odniesienie do schematu
- Odniesienie do schematu kategorii
Migracja do Storyblok
Ogólne informacje
- Oficjalna strona Storyblok
- Ceny i plany Storyblok
Dokumentacja
- Zrozumienie interfejsu użytkownika
- Struktury treści
- Konfigurowanie struktury treści bloga w Storyblok
Komponenty globalne
- Jak zbudować nawigację w menu nagłówka witryny za pomocą Storyblok
- Most Storyblok V2
Powiązane z SEO
- Jak wygenerować mapę witryny a445r za pomocą bezgłowego CMS?
- https://www.storyblok.com/apps/seo
Webhooki i budowanie haczyków
- Wszystko o webhookach
- Jak korzystać z webhooków Storyblok
- Hosting kompilacji haków - przykład Netlify
Skrypty i pakiety
- Universal JavaScript SDK dla API Storyblok: https://github.com/storyblok/storyblok-js-client
- Migracja WP do Storyblok helper: https://github.com/storyblok/wordpress-importer
Jamstack
- Strona Jamstack
- Lista statycznych generatorów witryn dla witryn Jamstack
Wniosek
Po przeczytaniu tego artykułu dowiesz się, dlaczego konfiguracja bezgłowa poprawi Twój projekt, jak przeprowadzić migrację z projektu WordPress do bezgłowego systemu CMS, takiego jak Storyblok, oraz jak ulepszać i rozszerzać swój projekt.
Jak widzieliście, możliwości konfiguracji bezgłowej są nieograniczone . 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?