Cara Bermigrasi Dari WordPress Ke CMS Tanpa Kepala

Artikel ini telah didukung dengan baik oleh teman-teman terkasih kami di Storyblok, CMS tanpa kepala yang ramah dengan editor visual, komponen bersarang, dan blok konten yang dapat disesuaikan untuk situs web dan aplikasi. Terima kasih!

WordPress adalah pembuat situs web yang paling banyak digunakan di dunia; hampir setengah dari web telah menggunakan WordPress untuk membuat situs web mereka. Masuk akal, karena memungkinkan Anda membuat situs web dengan cepat dan memiliki ekosistem plugin yang kaya untuk membantu Anda menskalakan situs Anda.

Namun teknologi terus berkembang, dan semakin banyak pilihan yang memudahkan untuk membuat situs web. Selain itu, mereka memberi kami kemungkinan untuk meningkatkan kinerja situs web dan memiliki lebih banyak kontrol dan keamanan atas aplikasi.

Arsitektur WordPress awal adalah monolitik , sehingga antarmuka pengguna dan akses data digabungkan pada platform yang sama.

Sejak pengenalan REST API di WordPress, ini dapat digunakan tanpa kepala, memungkinkan pengembang untuk menggunakannya sebagai backend dan memiliki front-end di proyek yang berbeda.

Dengan cara yang dipisahkan ini, model dan pengontrol dibundel di sisi WordPress , menangani manipulasi data dan interaksi basis data. Sementara itu, front-end hanya berinteraksi dengan REST API melalui klien HTTP.

Tetapi ini juga memiliki beberapa kelemahan, Anda masih perlu mengonfigurasi dan memperbarui WordPress, membuatnya aman dan bergantung pada teknologi mereka untuk pengembangan fungsionalitas baru.

Bacaan Terkait di SmashingMag

Bagi Anda yang baru memulai di dunia tanpa kepala, artikel ini akan membantu Anda memahami seluk beluk di baliknya dan mengapa semua orang mulai bermigrasi.

• “CMS Tanpa Kepala Dijelaskan Dalam 5 Menit Efektif”
• “Pikirkan Kembali Strategi Konten Anda Untuk CMS Tanpa Kepala”
• “Bagaimana Berpikir Dalam Komponen Dapat Meningkatkan Produktivitas Anda”
• Daftar artikel yang dikurasi terkait dengan “Headless” →

Tapi Mengapa Bermigrasi Ke CMS Tanpa Kepala?

Mempertimbangkan bahwa artikel ini akan menunjukkan cara bermigrasi dari WordPress ke Headless CMS, WordPress mungkin adalah pengaturan Anda saat ini.

CMS Tanpa Kepala akan memberi kita kebebasan untuk fokus hanya pada proyek front-end , dapat memilih teknologi yang kita kenal, dan pada struktur data kita. Pada akhirnya, itu mengurus manajemen konten dan pengiriman konten, sehingga kami dapat mengurus bagian rendering.

“CMS Tanpa Kepala adalah sistem yang menyediakan fitur yang sama seperti Sistem Manajemen Konten (CMS) dan lebih banyak lagi, semuanya diekspos melalui API.”

Jenis pengaturan ini sangat berguna bagi perusahaan yang memiliki banyak situs dan ingin mengurangi biaya atau menyederhanakan proses. Arsitektur tanpa kepala memungkinkan perusahaan-perusahaan ini memusatkan manajemen konten dalam satu antarmuka administrasi , menyediakan API yang akan digunakan oleh halaman web perusahaan yang berbeda.

Penggunaan umum lainnya dari arsitektur tanpa kepala adalah untuk membuat proyek front-end yang mewakili merek perusahaan. Dengan cara ini, semua produk yang diluncurkan perusahaan akan memiliki tampilan dan nuansa yang sama, tetapi masing-masing akan memiliki kontennya sendiri, dikelola di panel administrasi yang sama.

Catatan : Contoh ini dapat dengan mudah dilihat di situs web konferensi seperti JSWorld Conference dan VueJS Amsterdam yang, karena dari pencipta yang sama, proyek front-endnya sama, hanya kontennya yang berubah.

Berbeda dengan CMS seperti WordPress, dalam CMS Headless Anda memiliki panel administrasi yang telah dikonfigurasi dan dipelihara , dan terkadang juga dihosting, untuk Anda. Untuk mulai membuat konten, Anda hanya perlu membuat akun, masuk, dan Anda akan dapat membuat, mengedit, menggandakan, dan menghapus konten Anda, mengelola pengguna, menerjemahkan konten, dan bekerja dengan alur kerja publikasi, antara lain.

CMS tanpa kepala akan memudahkan orang-orang di tim Anda untuk memahami alur kerja, apakah mereka pembuat konten atau pemasar, sesuatu yang perlu diingat jika Anda bukan satu-satunya yang akan mengedit konten.

Perlu dicatat bahwa beberapa CMS Tanpa Kepala, tidak hanya berfokus untuk menawarkan layanan yang sudah ditawarkan oleh CMS seperti WordPress kepada Anda. Ini juga menyediakan layanan seperti CDN gambar untuk mengubah ukuran atau memformat ulang gambar Anda dengan cepat, atau keamanan tambahan melalui pencadangan S3.

Memiliki pengaturan ini tidak hanya akan memberi Anda kebebasan, keamanan, dan kenyamanan, tetapi juga akan meningkatkan kinerja aplikasi Anda tanpa layanan pihak ketiga. Hanya dengan menghubungkan proyek front-end Anda melalui klien HTTP dan mendapatkan komponen dan data, Anda akan siap dan berjalan.

Manfaat Pergi Tanpa Kepala Dan Saat Itu Masuk Akal

Arsitektur WordPress sering kali tidak menawarkan kemungkinan yang terkadang kita butuhkan saat bekerja di situs web, terutama dalam hal mengoptimalkan kinerja , salah satu poin terpenting saat memeringkat situs kita di mesin pencari seperti Google dan terutama sekarang setelah Web Vitals aktif dan berlari.

Tetapi jelas bahwa jika kami memiliki situs pribadi yang hanya kami sendiri yang mengerjakannya, maka tidak perlu memigrasikannya ke pengaturan tanpa kepala. Namun, jika lebih banyak orang yang terlibat dalam proyek itu (bukan hanya pengembang tetapi pembuat konten atau tim pemasaran), maka kita harus mempertimbangkan untuk mengadopsi CMS Tanpa Kepala.

Bagaimana CMS Tanpa Kepala Membantu Kami Meningkatkan Kinerja Situs Web Kami Dan Kualitas Proyek Front-End Kami?

• Dengan memungkinkan Anda mengembangkan front-end dengan cara yang sepenuhnya independen dari platform tempat Anda mengedit konten.

  Teknologi yang Anda pilih adalah pilihan Anda sendiri , jika Anda ingin meningkatkan proyek Anda ke kerangka kerja front-end terbaru, Anda tidak akan bergantung pada back-end dan dapat melakukannya tanpa harus memikirkan kembali migrasi.

• Memungkinkan Anda membuat proyek multiplatform tanpa harus bergantung pada panel administrasi yang berbeda.

  Pada akhirnya, jika untuk aplikasi Anda memerlukan deskripsi yang lebih pendek daripada situs web utama, Anda selalu dapat menggunakan bidang "short_description" baru dan hanya menampilkannya di bagian depan aplikasi tertentu.

• Hal ini dimaksudkan untuk mempermudah pengembangan dan menyederhanakan proses pembuatan situs, serta penskalaannya.

  Dengan mengisolasi front-end sepenuhnya, kami dapat mengubah tampilan visual seluruh aplikasi kami tanpa mengubah struktur konten kami.

• Selalu menawarkan layanan yang memungkinkan kami untuk mengoptimalkan aset kami dan kecepatan respons saat mereka disajikan kepada kami. Pada akhirnya semua data kami akan dikirimkan melalui jaringan CDN.

Jaringan pengiriman konten (CDN), adalah jaringan server proxy yang terdistribusi secara geografis dan pusat datanya. Tujuannya adalah untuk menyediakan ketersediaan dan kinerja tinggi dengan mendistribusikan layanan secara spasial relatif kepada pengguna akhir.

“

Bagaimana Jika Kita Khawatir Tentang Bagaimana Ini Akan Bekerja Dengan Struktur Merek Atau Perusahaan Kita?

• Selain mendukung aplikasi lintas platform, ini juga memungkinkan kami untuk menjaga konsistensi merek .

  Memiliki front-end sebagai proyek dasar dan memiliki banyak ruang dalam CMS Tanpa Kepala, memungkinkan Anda untuk memiliki konsistensi antara produk Anda dan membuat skalabilitas lebih mudah karena kami memiliki lebih sedikit kode untuk dipelihara.

• Meskipun tidak semua CMS tanpa kepala memiliki manfaat ini, CMS tanpa kepala yang kami migrasikan, Storyblok, memiliki Editor Visual, yang memungkinkan terciptanya kemandirian di antara tim . Editor atau pembuat konten dapat mengakses panel untuk mengedit konten yang ada atau membuat konten baru, dapat melihat pratinjau tampilannya sebelum dipublikasikan. Jadi mereka tidak perlu melibatkan tim pengembangan dalam proses ini dan dapat melakukan pekerjaan mereka dengan lebih efisien.

• Ini juga merampingkan manajemen konten dengan memungkinkan Anda mengatur alur kerja konten Anda sendiri. Anda dapat menentukan tahapan yang harus dilalui suatu konten sebelum dipublikasikan dan, hanya jika berhasil melewati proses, konten akan dipublikasikan.

Bagaimana CMS Tanpa Kepala Dapat Menghemat Waktu Dibandingkan Dengan CMS Tradisional?

• Menjaga keamanan platform dan memperbaruinya atas nama Anda. Setiap kali ada bug atau pengguna memerlukan fitur baru, tim di belakang Headless CMS Anda akan mengembangkannya untuk Anda, Anda hanya perlu mulai menggunakannya!
• Terus meningkatkan pengalaman pengguna (UX) dan desain (UI) untuk Anda, sehingga pembuat konten dan pengembang merasa nyaman membuat bidang, komponen, atau halaman baru. Tetapi tidak hanya pada aspek visual, tetapi mereka juga akan mencari untuk meningkatkan kinerja database, sehingga Anda mendapatkan konten Anda secara instan dan melupakan semua pekerjaan yang terlibat.

Monolitik vs Tanpa Kepala

Setelah melihat keuntungan yang dapat dibawa oleh pengaturan tanpa kepala ke proyek kami dan orang-orang yang mengerjakannya, saya pikir inilah saatnya untuk melihat langkah-langkah yang kami perlukan untuk memigrasikan proyek kami.

Yang Perlu Anda Ingat Saat Pergi Tanpa Kepala

Seperti yang telah kami sebutkan, CMS Tanpa Kepala memungkinkan pemisahan yang jelas antara pembuat konten dan pengembang. Dengan cara ini (dalam Headless CMS), pengembang berfokus pada pembuatan struktur konten, yang akan direpresentasikan dalam proyek front-end, dan editor akan bertanggung jawab untuk menggunakan komponen dan mengisinya dengan konten di panel admin .

Jenis Konten Yang Dapat Kami Buat Dalam CMS Tanpa Kepala

1. Jenis entri atau template

Mirip dengan Jenis Posting Kustom di WordPress tetapi dengan lebih banyak kebebasan dan ekstensibilitas dalam hal tipe data dan editor.

Saat Anda pergi untuk membuat entri konten baru di dasbor Anda, Anda berharap dapat memilih jenisnya tergantung pada situasinya. Misalnya, jika Anda memiliki situs web dengan blog, Anda ingin memiliki beberapa jenis templat, satu untuk halaman dengan daftar atau konten dinamis yang disebut " halaman " dan satu untuk setiap entri blog " posting ".

Tergantung pada CMS tanpa kepala yang Anda pilih, namanya akan bervariasi tetapi konsepnya sama. Di Storyblok jenis entitas ini disebut Content Type . "Jenis Konten" menentukan jenis entri konten dan dapat menampung bidang dasar untuk entri konten Anda. Secara default, kami memiliki tipe konten "Halaman".

2. Komponen yang dapat digunakan kembali

Dalam CMS Tanpa Kepala, Anda dapat membuat, selain Tipe Konten, komponen bersarang dan menggunakannya kembali di antara tipe konten dan komponen lainnya. Di Storyblok, jenis komponen ini — seperti yang mungkin Anda perhatikan dari namanya — disebut Blok .

Untuk menggunakannya dalam Tipe Konten seperti halaman, Anda perlu membuat bidang dalam skema blok tipe. Bidang ini memungkinkan Anda untuk menambahkan komponen bersarang ke halaman Anda sambil menambahkan konten.

Tapi, pada prinsipnya, kita tidak akan membutuhkan komponen seperti itu selama migrasi. Ini hanya memberi Anda fleksibilitas untuk membuat aplikasi yang kuat dan dinamis tanpa harus melibatkan pengembang.

Misalnya, ketika seorang anggota tim pemasaran ingin menambahkan Pahlawan baru ke halaman Tentang kami, jika komponen Pahlawan dibuat bersarang dan halaman memiliki bidang Blok, orang pemasaran dapat menambahkan Pahlawan tanpa harus melibatkan pengembang.

Merender Data Yang Berasal Dari CMS Tanpa Kepala

Saat kami mendefinisikan struktur konten kami di panel Headless CMS, kami harus mempertimbangkan kerangka kerja mana yang ingin kami buat dengan proyek front-end kami dan klien HTTP mana yang akan kami gunakan.

Saat memilih kerangka kerja, kita harus mempertimbangkan beberapa faktor:

Apakah saya dan tim saya sudah familiar dengan teknologi ini?

Apakah itu memungkinkan saya untuk merender konten saya dalam jenis rendering yang dibutuhkan proyek saya?

Apakah ada plugin atau modul yang memfasilitasi integrasi dengan CMS Headless yang saya gunakan?

Dalam kebanyakan kasus, situs statis akan cukup dan akan selalu menjadi jawaban yang paling ekonomis dan berkinerja tinggi. Jadi, Anda hanya perlu mencari generator situs statis untuk teknologi yang Anda kenal, misalnya Nuxt for Vue atau Next for the React library.

Menghubungkan dua hal ini, CMS Tanpa Kepala dan pembuat situs statis dianggap sebagai kumpulan praktik terbaik pengembangan web yang berfokus pada penyediaan kinerja tertinggi, keamanan, dan biaya terendah. Arsitektur ini juga dikenal sebagai Jamstack. Ini adalah arsitektur yang dirancang untuk membuat web lebih cepat, lebih aman, dan lebih mudah untuk diskalakan. Itu dibangun di atas banyak alat dan alur kerja yang disukai pengembang, dan yang membawa produktivitas maksimum.

Dengan memanfaatkan kerangka kerja yang trendi, Anda akan mendapatkan panduan integrasi dengan Headless CMS yang akan Anda gunakan, dan sebagian besar dari mereka telah memiliki modul atau paket yang memungkinkan Anda memperoleh informasi dari API dan dalam banyak kasus memperpanjangnya.

Satu-satunya hal yang tersisa untuk Anda lakukan adalah menentukan struktur komponen Anda tentang bagaimana Anda telah menyusun data di CMS Tanpa Kepala Anda dan mengotomatiskan proses penerbitan konten. Misalnya, dengan menggunakan Webhooks yang disediakan oleh Headless CMS, Anda akan dapat memulai proses pembuatan di hosting favorit Anda dengan kait pembuatannya setelah konten dipublikasikan.

Jumlah Waktu yang Anda Butuhkan

Seperti halnya migrasi apa pun, waktu yang dibutuhkan akan selalu bergantung secara proporsional pada kompleksitas proyek Anda. Jika kita berbicara tentang situs WordPress umum, Anda hanya perlu memigrasikan jenis Posting yang telah Anda tetapkan atau yang datang secara default di dalamnya, seperti Halaman, Postingan dan Kategori, dan kontennya.

Sebaliknya, jika Anda telah menyesuaikan proyek Anda dengan beberapa plugin, Anda harus mengembangkannya melalui proyek front-end atau menggunakan yang disediakan oleh Headless CMS Anda. Misalnya, jika kita sadar SEO dan karena itu menggunakan Yoast SEO di WordPress, kita akan memiliki plugin SEO Field-Type di Storyblok untuk membantu kita dalam transisi, tetapi kita masih harus mengembangkan peta situs kita di front-end dengan panduan untuk membantu kami.

Pada akhirnya, semua beban pengembangan akan jatuh pada proyek front-end, karena menyiapkan CMS Headless tidak akan memakan banyak waktu.

Tapi mari kita berhenti bicara dan mari kita lihat!

Langkah-langkah Untuk Memigrasikan Konten Kami Dari WordPress Ke Storyblok

Migrasi akan terdiri dari empat langkah, mulai dari pembuatan ruang di Headless CMS Storyblok kami yang baru hingga representasi konten yang dimigrasikan di proyek front-end kami, yang akan kami lihat secara detail di bawah dan di mana saya akan meninggalkan Anda sumber daya untuk membuat migrasi lebih mudah bagi Anda.

Mari kita mulai!

1. Membuat Ruang Di Storyblok

Untuk membuat ruang di Storyblok, Anda harus memiliki akun terlebih dahulu. Untuk melakukan ini, Anda harus memilih paket yang paling cocok untuk Anda.

Buka halaman Harga dan mulai dengan paket yang paling sesuai dengan kebutuhan Anda atau coba paket gratis untuk pengujian.

Buat akun Anda, dan Anda akan dapat mengakses panel.

Pilih 'Buat ruang baru' dan mari kita mulai!

Space adalah gudang konten. Anggap saja sebagai tempat untuk menyimpan semua konten yang terkait dengan satu proyek. Setiap ruang memiliki komponen, sumber data, aset, lingkungan, domain, kolaborator, dan izinnya sendiri.

Luangkan waktu untuk menjelajahi bagian di bilah sisi kiri. Mulailah dengan menelusuri yang berikut ini:

• Konten , ini akan menjadi folder tempat konten akan disimpan, tempat tim pemasaran akan menghabiskan sebagian besar waktunya.
• Aset , di mana semua gambar akan disimpan, yang kemudian bisa Anda dapatkan melalui layanan CDN, dioptimalkan dan dalam ukuran apa pun.
• Komponen , di mana Anda akan membuat jenis Konten dan komponen Bersarang .
• Pengaturan , bagian di mana Anda akan dapat mengonfigurasi data ruang Anda serta bahasa aplikasi Anda, alur kerja yang Anda inginkan untuk diikuti konten Anda sebelum dipublikasikan, izin pengguna, dll. Katakanlah area ini akan menjadi satu terkait dengan tim TI proyek.

Jika Anda masih ingin menjelajahi setiap opsi di dasbor sebelum masuk ke migrasi, saya sarankan untuk melihat Memahami UI oleh Storyblok.

Sekarang setelah Anda mengetahui sedikit tentang ekosistem Storyblok, saatnya untuk menentukan seperti apa konten aplikasi kita nantinya.

2. Mendefinisikan Model

Untuk memigrasikan konten WordPress ke Storyblok, langkah selanjutnya adalah membuat skema yang mendefinisikan struktur data WP dengan membuat Jenis Postingan di ruang Storyblok.

Mari kita mulai dengan halaman dan posting (Jenis Posting utama di situs WP mana pun), yang akan kita sebut page dan post di Storyblok.

Skema halaman di WP berisi bidang: judul , siput , gambar unggulan , tanggal, dan konten .

Catatan : Untuk melihat semua bidang yang terdapat dalam Jenis Posting, buka skema di referensi skema WP REST API.

Yang perlu Anda ketahui adalah, secara default, setiap Jenis Konten di Storyblok akan memiliki beberapa bidang yang sudah ditentukan untuk Anda, seperti Name , Slug , Tags , First publishing date , dan seterusnya.

Bidang-bidang itu dapat digunakan untuk memigrasikan konten dari WP. Anda hanya perlu memperluasnya dengan menambahkan fitur_gambar dan konten di Jenis Konten Halaman.

Buka bagian Komponen di ruang Anda, klik page yang dibuat secara default, hapus bidang isi dan tambahkan gambar_fitur sebagai jenis Assets > Images dan konten sebagai Rich-text .

Setelah skema page siap, mari beralih ke post . Untuk Jenis Konten Postingan, perlu menyertakan lebih banyak informasi, seperti gambar_fitur , kutipan , konten, dan hubungan dengan jenis lain seperti Penulis atau Kategori .

Karena Penulis dan Kategori juga akan memiliki kontennya sendiri, buka bagian Konten di bilah sisi dan buat beberapa folder bernama penulis dan kategori .

Setiap folder harus memiliki Tipe Konten default yang terkait. Untuk melakukannya, di bagian Komponen , buat Penulis dan Kategori sebagai Tipe Konten baru, lalu kaitkan Tipe Konten relatif ke setiap folder dengan mengklik tiga titik di sebelah kanan folder dan memilih Pengaturan.

Dengan cara ini, di Jenis Konten Postingan Anda dapat menambahkan bidang Opsi Tunggal atau Multi-Opsi dengan Cerita sumber dan arahkan ke folder yang dibuat untuk setiap bidang:

• Penulis
  Ini menentukan folder tempat mereka berada authors/ .
• Kategori
  Ini menentukan folder di mana mereka berada categories/ .

Catatan : Jika Anda ingin tahu lebih banyak tentang hubungan ini, lihat artikel Hubungan Penulis dan Artikel.

Sekarang setelah Anda melihat cara membuat beberapa Tipe Konten dan cara membuat hubungan di antara mereka, Anda harus menentukan model lainnya dengan mengikuti langkah yang sama.

Menambahkan Tipe Konten: Global

Dan Anda bertanya pada diri sendiri, bagaimana dengan konten yang akan dibagikan semua halaman saya? Suka menu navigasi, footer, dan elemen umum lainnya?

Jangan khawatir, Storyblok telah memikirkannya dan menawarkan kami panduan sederhana untuk mendefinisikan elemen global kami secara dinamis. Ini menunjukkan kepada kita cara membuat Tipe Konten global dan cara menggunakannya di bagian Konten .

3. Migrasi Konten

Sekarang saatnya untuk mulai memigrasikan konten yang telah Anda simpan. Untuk mengakses konten WP, Anda perlu mengakses REST JSON API. Akses jalur /wp-json , jika proyek disebarkan, atau ?rest_route=/ jika lokal.

Jika tidak satu pun dari dua rute yang berfungsi, periksa HTML halaman Anda untuk tautan di kepala dengan rel="https://api.w.org/" , seperti yang ditunjukkan dalam panduan penemuan WP, dan dapatkan yang benar .

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

Untuk membantu kami selama migrasi, pengembang Storyblok telah memberi kami plugin yang akan menghemat banyak pekerjaan. Plugin ini disebut wordpress-importir, di atasnya, dimungkinkan untuk menentukan Jenis Konten yang setara di Storyblok untuk jenis WP Post yang akan dimigrasi, dan itu akan mendorongnya ke ruang kami dan memigrasikan gambar ke bagian Aset kami untuk kami.

Catatan : Menggunakan skrip ini memerlukan simpul 14.0.0 karena menggunakan rangkaian opsional.

Membuat Skrip Migrasi

Hal pertama yang harus dilakukan adalah mengkloning repositori. Kemudian, instal paket NPM, menggunakan npm install atau yarn , dan buat file di root proyek sebagai migrationWPtoStoryblok.js . Untuk menjalankan skrip, Anda memerlukan skrip di package.json untuk menjalankannya, tambahkan:

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

Setelah semuanya siap, saatnya untuk mulai mendefinisikan skrip mengikuti spesifikasi README. Dan, seperti yang Anda lihat, hal berikutnya yang diperlukan adalah menemukan Space_id dan token OAuth untuk terhubung ke ruang Storyblok.

• Space_id ada di bagian Pengaturan di bilah sisi, segera setelah Anda mengkliknya, Anda akan melihatnya di sisi kanan.
• Untuk menghasilkan token OAuth , Anda harus pergi ke bagian atas bilah sisi, klik panah kecil tepat di sebelah logo Storyblok, dan buka Akun Saya . Jika kita gulir ke bawah kita akan melihat bagian Token akses pribadi , buat satu, dan salin.

Setelah mendapatkan kedua rahasia, Anda dapat menambahkannya ke awal skrip bersama dengan URL JSON API proyek Anda:

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

Seperti yang dijelaskan di bagian sebelumnya, Jenis Konten Halaman di Storyblok sama dengan Jenis Posting di halaman WP. Di blok kode di bawah ini, Anda akan melihat di mana Anda harus menentukan masing-masing.

Dan, setelah Jenis Posting dan Jenis Konten ditentukan, sekarang saatnya untuk menentukan nama bidang yang digunakan dalam jenis entitas ini di WP dan nama yang setara di Storyblok, dalam opsi 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" } } ] })

Catatan : Agar migrasi berfungsi dengan benar, pastikan tautan permanen dipilih berdasarkan nama entri dan tidak sesederhana itu. Jika tidak, skrip tidak akan membuat hubungan induk-anak antar halaman.

Dalam schema_mapping Anda dapat menentukan beberapa jenis bidang, ini dapat berupa:

• Bidang sederhana , seperti title .
• Sub-properti bidang, seperti dalam hal ini URL gambar fitur.
  Catatan : Plugin itu sendiri menangani migrasi gambar ke ruang Storyblok melalui URL terkait di links.wp:featuredmedia.0 .

• Bidang dimigrasikan ke blok bersarang di Storyblok.

  Bayangkan Anda ingin membuat komponen di Storyblok untuk menentukan teks kaya situs Anda sehingga semua jenis posting yang menggunakannya memiliki gaya dan opsi yang sama.

  Untuk itu, Anda dapat menggunakan format objek dan menentukan nama bidang dalam model Storyblok di bawah properti bidang , nama komponen yang ingin Anda simpan di dalam bidang itu, dan nama bidang di dalam komponen tempat konten akan dimigrasi.

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

Halaman Jenis Entri

Sekarang Anda tahu cara menentukan jenis bidang, untuk skema halaman, itu akan terlihat seperti di blok kode di bawah ini.

Plugin akan menjaga hubungan induk-anak antara halaman dengan membuat folder di Storyblok di bawah slug induk dan mengaitkan induk sebagai rumah folder itu.

Selanjutnya, jika bidang konten berisi gambar , plugin juga akan memigrasikannya untuk Anda!

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

Entri Jenis Posting

Postingan memiliki skema yang mirip dengan halaman tetapi, dalam hal ini, untuk menyimpannya dalam folder, Anda harus menentukan nama folder di bawah jenis entri:

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

Kategori Jenis Entri

Dan setelah skema untuk posting ditentukan, masuk akal untuk mendefinisikan skema untuk kategori sehingga mereka dapat dikaitkan seperti yang dijelaskan di bagian sebelumnya.

Untuk menentukan folder yang berisi mereka sebagai kategori dan bukan sebagai kategori, nama defaultnya, Anda harus membuka opsi Permalinks di admin WordPress dan mengubah opsi basis Kategori menjadi categories . Kemudian bidang multi-opsi dari entri Postingan akan menjadi bidang yang memiliki hubungan dengan kategori yang sesuai.

Catatan : Langkah-langkah ini sama dengan langkah yang harus diikuti untuk memigrasikan penulis dan menautkannya ke artikel.

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

Skrip Akhir Lengkap

Kode di bawah ini akan menjadi skrip migrasi yang dihasilkan dari proyek WP dengan tipe dasar ke ruang Storyblok yang telah kami buat.

 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. Buat Proyek Front-End

Sekarang konten sudah tersimpan di dasbor Storyblok, saatnya menghubungkan proyek Front-end ke Storyblok.

Apa pun kerangka kerja atau pustaka JS Anda, Storyblok menyediakan klien JavaScript yang akan membantu Anda dalam integrasi. Selain itu, jika Anda menggunakan kerangka kerja tertentu, Anda akan menemukan paket lain yang akan memudahkan jalannya, seperti di Nuxt modul storyblok-nuxt .

API JavaScript ini juga akan menyertakan jembatan antara Storyblok dan aplikasi Front-end Anda. Bridge bertanggung jawab untuk berkomunikasi melalui iframe dengan Storyblok untuk memberi tahu antarmuka pengeditan komponen mana yang akan dibuka ketika pengguna mengkliknya.

Berikut adalah daftar tutorial yang dapat Anda temukan di Storyblok untuk menghubungkan proyek Front-end Anda.

Catatan : Jika Anda tidak menemukan teknologi Anda di antara mereka, jangan khawatir ada banyak tutorial lain di situs web Storyblok, cari milik Anda di mesin pencari, dan jika Anda tidak menemukannya, saya mendorong Anda untuk menghubungi mereka, dan Anda akan membantu lebih banyak orang!

• Lanjut
• Gatsby
• Vue
• Nuxt
• sudut
• Langsing
• Bara
• AMP

5. Host Proyek Front-End Anda Dan Otomatiskan Deploy

Setelah proyek Anda siap untuk masuk ke produksi, Anda memilih penyedia hosting dan menautkan repositori Anda untuk penerapan yang mudah, lalu Anda bertanya pada diri sendiri:

Bagaimana cara menyebarkan kembali situs statis saya jika saya menerbitkan entri di Storyblok?

Jawabannya sangat sederhana: dengan menggunakan webhook yang ditawarkan oleh Storyblok dan build hook dari hosting Anda.

Untuk memberi Anda contoh nyata, Anda dapat membuat URL kait pembangunan di Netlify dalam bagian penerapan; URL yang dibuat untuk Storyblok di hook build akan masuk ke bidang Pengaturan → Webhooks → Cerita diterbitkan & tidak diterbitkan di ruang Storyblok.

Panduan Dan Alat yang Kami Gunakan Selama Migrasi

Mari kita rekap tautan yang telah membantu dalam migrasi konten dan tautan yang membantu memahami fungsi REST API dan CMS tanpa kepala yang Anda migrasikan.

Diperlukan Dokumentasi WP REST API

REST API

• Referensi Titik Akhir Pengembang REST API
• Menggunakan REST API
• Menemukan API dan rutenya

skema

• Referensi skema halaman
• Referensi skema posting
• Referensi skema kategori

Migrasi ke Storyblok

Informasi Umum

• Situs web resmi Storyblok
• Harga & Paket Storyblok

Dokumentasi

• Memahami UI
• Struktur Konten
• Menyiapkan Struktur Konten Blog di Storyblok

Komponen Global

• Cara membuat navigasi menu header situs web dengan Storyblok
• Jembatan Storyblok V2

Terkait SEO

• Bagaimana cara menghasilkan Peta Situs a445r dengan CMS tanpa kepala?
• https://www.storyblok.com/apps/seo

Webhook Dan Bangun Kait

• Segala sesuatu tentang Webhook
• Cara menggunakan webhook Storyblok
• Kait pembuatan hosting - Contoh Netlify

Script Dan Paket

• Universal JavaScript SDK untuk API Storyblok: https://github.com/storyblok/storyblok-js-client
• Migrasi WP ke pembantu Storyblok: https://github.com/storyblok/wordpress-importer

tumpukan jam

• Situs web Jamstack
• Daftar Generator Situs Statis untuk Situs Jamstack

Kesimpulan

Setelah membaca artikel ini, Anda akan memiliki apa yang Anda perlukan untuk memahami mengapa pengaturan tanpa kepala akan meningkatkan proyek Anda, cara bermigrasi dari proyek WordPress Anda ke CMS tanpa kepala seperti Storyblok dan cara terus meningkatkan dan memperluas proyek Anda.

Seperti yang telah Anda lihat, kemungkinan pengaturan tanpa kepala tidak terbatas . 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?