Как перейти с WordPress на безголовую CMS
Опубликовано: 2022-03-10Эта статья была любезно поддержана нашими дорогими друзьями из Storyblok, удобной безголовой CMS с визуальным редактором, вложенными компонентами и настраиваемыми блоками контента для веб-сайтов и приложений. Спасибо!
WordPress — самый популярный конструктор сайтов в мире; почти половина Интернета использовала WordPress для создания своего веб-сайта. Это имеет смысл, потому что он позволяет быстро создавать веб-сайты и имеет богатую экосистему плагинов, которые помогут вам масштабировать ваш сайт.
Но технологии развиваются, и появляется все больше возможностей, упрощающих создание веб-сайтов. Кроме того, они дают нам возможность повысить производительность веб-сайта и обеспечить больший контроль и безопасность приложения.
Первоначальная архитектура WordPress является монолитной , поэтому пользовательский интерфейс и доступ к данным объединены на одной платформе.
С момента появления REST API в WordPress его можно использовать безголовым способом, что позволяет разработчикам использовать его в качестве бэкэнда, а внешний интерфейс — в другом проекте.
Таким образом, модели и контроллеры объединяются на стороне WordPress , обрабатывая манипулирование данными и взаимодействие с базой данных. Между тем, интерфейс взаимодействует с REST API только через HTTP-клиент.
Но у этого также есть некоторые недостатки, вам все еще нужно настраивать и обновлять WordPress, делать его безопасным и зависеть от их технологии для разработки новых функций.
Связанное Чтение на SmashingMag
Для тех из вас, кто только начинает работать с безголовым миром, эти статьи помогут понять все тонкости, стоящие за ним, и почему все начинают мигрировать.
- «Безголовая CMS объясняется за 5 эффективных минут»
- «Переосмыслите свою контент-стратегию для безголовой CMS»
- «Как мышление компонентами может повысить вашу производительность»
- Кураторский список статей, связанных с «Безголовым» →
Но зачем переходить на безголовую CMS?
Принимая во внимание, что в этой статье будет показано, как перейти с WordPress на безголовую CMS, WordPress, вероятно, является вашей текущей установкой.
Безголовая CMS даст нам свободу сосредоточиться только на внешнем проекте , имея возможность выбирать технологию, с которой мы знакомы, и структуру наших данных. В конце концов, он берет на себя управление контентом и доставку контента, так что мы можем позаботиться о части рендеринга.
«Безголовая CMS — это система, которая предоставляет те же функции, что и система управления контентом (CMS), и даже больше, все они доступны через API».
Этот тип настройки особенно полезен для компаний, которые имеют несколько сайтов и хотят сократить расходы или упростить процессы. Безголовая архитектура позволяет этим компаниям централизовать управление контентом в едином административном интерфейсе , предоставляя API-интерфейсы, которые будут использоваться различными веб-страницами компании.
Еще одно распространенное использование безголовой архитектуры — создание интерфейсного проекта, представляющего бренд компании. Таким образом, все продукты, которые запускает компания, будут иметь одинаковый внешний вид, но каждый из них будет иметь свой собственный контент, управляемый в одной и той же панели администрирования.
Примечание . Этот пример можно легко увидеть на веб-сайтах конференций, таких как JSWorld Conference и VueJS Amsterdam, которые, будучи созданными одними и теми же создателями, имеют тот же интерфейсный проект, меняется только содержимое.
В отличие от CMS, такой как WordPress, в Headless CMS у вас есть уже настроенная и поддерживаемая панель администрирования , а иногда и размещенная для вас. Чтобы начать создавать контент, вам просто нужно создать учетную запись, войти в систему, и вы сможете создавать, редактировать, дублировать и удалять свой контент, управлять пользователями, переводить контент и работать с рабочими процессами публикации, среди прочего.
Безголовая CMS облегчит людям в вашей команде понимание рабочего процесса, будь то создатели контента или маркетологи, о чем следует помнить, если вы не единственный, кто будет редактировать контент.
Стоит отметить, что некоторые Headless CMS не только предлагают вам услуги, уже предлагаемые CMS, такой как WordPress. Он также предоставляет такие услуги, как CDN изображений для изменения размера или форматирования изображений на лету, или дополнительную безопасность с помощью резервных копий S3.
Наличие такой настройки не только даст вам свободу, безопасность и комфорт, но и повысит производительность вашего приложения без сторонних сервисов. Просто подключив свой внешний проект через HTTP-клиент и получив компоненты и данные, вы будете готовы к работе.
Преимущества безголового и когда это имеет смысл
Архитектура WordPress часто не предлагает возможности, которые нам иногда нужны при работе с веб-сайтом, особенно когда речь идет об оптимизации производительности , что является одним из наиболее важных моментов при ранжировании нашего сайта в поисковой системе, такой как Google, и особенно сейчас, когда Web Vitals работает. и работает.
Но понятно, что если у нас есть персональный сайт, над которым работаем только мы сами, то не обязательно его мигрировать на безголовый сетап. Однако, если в этом проекте задействовано больше людей (не только разработчиков, но и создателей контента или маркетинговых команд), то нам следует рассмотреть возможность внедрения Headless CMS.
Как безголовая CMS может помочь нам улучшить производительность нашего веб-сайта и качество нашего внешнего проекта?
Позволяя вам разрабатывать внешний интерфейс таким образом, который полностью не зависит от платформы, на которой вы редактируете свой контент.
Выбранная вами технология — это ваш собственный выбор . Если вы хотите обновить свой проект до новейшей интерфейсной среды, вы не будете зависеть от серверной части и сможете сделать это без необходимости переосмысления миграций.
Позволяет создавать мультиплатформенные проекты, не завися от разных панелей администрирования.
В конце концов, если для приложения вам нужно более короткое описание, чем основной веб-сайт, вы всегда можете использовать новое поле «short_description» и просто представить его во внешнем интерфейсе этого конкретного приложения.
Он призван облегчить разработку и упростить процесс создания сайта, а также его масштабирования.
Имея полностью изолированный интерфейс, мы можем изменить внешний вид всего нашего приложения, не изменяя структуру нашего контента.
Всегда предлагая услуги, которые позволят нам оптимизировать наши активы и скорость реагирования , с которой они нам обслуживаются. В конечном итоге все наши данные будут доставляться через сети CDN.
Сеть доставки контента (CDN) — это географически распределенная сеть прокси-серверов и их центров обработки данных. Цель состоит в том, чтобы обеспечить высокую доступность и производительность за счет пространственного распределения службы по отношению к конечным пользователям.
“
Что, если нас беспокоит, как это будет работать со структурой нашего бренда или компании?
Помимо поддержки кроссплатформенных приложений, это также позволяет нам поддерживать целостность бренда .
Наличие внешнего интерфейса в качестве базового проекта и наличие нескольких пространств в Headless CMS позволяет вам обеспечить согласованность между вашими продуктами и упрощает масштабируемость, поскольку нам нужно поддерживать меньше кода.
Хотя не все безголовые CMS имеют это преимущество, безголовая CMS, на которую мы мигрируем, Storyblok, имеет визуальный редактор, который позволяет создавать независимость между командами . Редакторы или создатели контента могут получить доступ к панели для редактирования существующего контента или создания нового контента, имея возможность предварительно просмотреть, как он будет выглядеть перед публикацией. Таким образом, им не нужно будет вовлекать в этот процесс команду разработчиков, и они смогут выполнять свою работу более эффективно.
Он также упрощает управление контентом, позволяя настроить собственный рабочий процесс контента . Вы можете определить этапы, которые должен пройти элемент контента перед публикацией, и только после успешного прохождения процесса он будет опубликован.
Как безголовая CMS может сэкономить время по сравнению с традиционной CMS?
- Забота о поддержании безопасности платформы и обновлении ее от вашего имени. Всякий раз, когда возникает ошибка или пользователям требуется новая функция, команда Headless CMS разработает ее для вас, вам просто нужно начать ее использовать!
- Постоянно улучшаем пользовательский интерфейс (UX) и дизайн (UI) для вас, чтобы создатели контента и разработчики чувствовали себя комфортно, создавая новые поля, компоненты или страницы. Но не только в визуальном аспекте, они также будут стремиться улучшить производительность базы данных, чтобы вы мгновенно получали свой контент и забыли обо всей связанной с этим работе.
Монолитный против безголового
Характерная черта | Монолитный | Обезглавленный |
---|---|---|
Архитектура | Связанный: связанный внешний интерфейс | Decoupled: независимый интерфейсный проект |
Технология | Вам придется использовать тот, в котором разрабатывается проект | Свобода выбора передовой технологии |
Кроссплатформенность | Ограничено одним интерфейсом за раз | Подключается к любым фронтенд-проектам |
Рабочий процесс контента | ограничительный | Обычай |
Безопасность и обновления | Вы заботитесь | Он заботится о вас |
Увидев преимущества, которые безголовая установка может дать нашему проекту и людям, которые над ним работают, я думаю, что пришло время рассмотреть шаги, необходимые для переноса нашего проекта.
Что нужно иметь в виду, когда вы идете без головы
Как мы уже упоминали, Headless CMS позволяет четко разделить обязанности между создателями контента и разработчиками. Таким образом (в Headless CMS) разработчик сосредотачивается на создании структуры контента, которая будет представлена во внешнем проекте, а редактор будет отвечать за использование компонентов и наполнение их контентом в панели администратора. .
Тип контента, который мы можем создать в безголовой CMS
1. Типы записей или шаблон
Подобно пользовательским типам записей в WordPress, но с большей свободой и расширяемостью, когда речь идет о типах данных и редакторах.
Когда вы переходите к созданию новой записи контента на панели инструментов, вы ожидаете, что сможете выбрать ее тип в зависимости от ситуации. Например, если у вас есть веб-сайт с блогом, вам понадобится несколько типов шаблонов: один для страниц со списками или динамическим контентом, называемый « страница », и один для каждой записи в блоге « пост ».
В зависимости от выбранной вами безголовой CMS название может различаться, но концепция остается неизменной. В Storyblok эти типы сущностей называются Content Type . «Типы контента» определяют тип записи контента и могут содержать основные поля для ваших записей контента. По умолчанию у нас есть тип контента «Страница».
2. Многоразовые компоненты
В Headless CMS вы можете создавать в дополнение к типам контента вложенные компоненты и повторно использовать их между типами контента и другими компонентами. В Storyblok этот тип компонента — как вы могли заметить из его названия — называется Blok .
Чтобы использовать их в типе контента , таком как страница, вам нужно будет создать поле в схеме блоков типов. Это поле позволяет вам добавлять вложенные компоненты на вашу страницу при добавлении содержимого.
Но, в принципе, такие компоненты при миграции нам не понадобятся. Это просто дает вам возможность создавать надежные и динамичные приложения без участия разработчика.
Например, когда член маркетинговой команды хочет добавить нового Героя на страницу «О нас», если компонент «Герой» был создан как вложенный, а на странице было поле «Блоки», специалист по маркетингу может добавить Героя, не привлекая разработчик.
Рендеринг данных, поступающих из Headless CMS
Поскольку мы определяем структуру нашего контента на панели Headless CMS, мы должны учитывать, с какой структурой мы хотим создать наш интерфейсный проект и какой HTTP-клиент мы будем использовать.
При выборе фреймворка необходимо учитывать несколько факторов:
Я и моя команда знакомы с этой технологией?
Позволяет ли он отображать мой контент в том виде, в котором он нужен моему проекту?
Есть ли у него плагины или модули, облегчающие интеграцию с Headless CMS, которую я использую?
В большинстве случаев статического сайта будет достаточно, и он всегда будет наиболее экономичным и высокопроизводительным решением. Итак, вам остается только искать генератор статических сайтов для знакомой вам технологии, например, Nuxt для Vue или Next для библиотеки React.
Соединяя эти две вещи, Headless CMS и конструктор статических сайтов рассматриваются как набор лучших практик веб-разработки, ориентированных на обеспечение максимальной производительности, безопасности и минимальной стоимости. Эта архитектура также известна как Jamstack. Эта архитектура предназначена для того, чтобы сделать Интернет быстрее, безопаснее и проще в масштабировании. Он основан на многих инструментах и рабочих процессах, которые нравятся разработчикам и обеспечивают максимальную производительность.
Используя модные фреймворки, вы будете уверены в руководстве по интеграции с Headless CMS, с которой собираетесь работать, и в большинстве из них уже есть модуль или пакет, позволяющий получать информацию из API и во многих случаях продлить его.
Единственное, что вам осталось сделать, это определить структуру ваших компонентов относительно того, как вы структурировали данные в своей Headless CMS, и автоматизировать процесс публикации контента. Например, используя Webhooks, которые предоставляет вам Headless CMS, вы сможете начать процесс сборки на своем любимом хостинге с помощью его сборочных хуков после публикации контента.
Количество времени, которое вам понадобится
Как и при любой миграции, необходимое время всегда будет пропорционально зависеть от сложности вашего проекта. Если мы говорим об обычном сайте WordPress, вам нужно будет перенести только те типы сообщений, которые вы определили или которые присутствуют в нем по умолчанию, такие как страницы, сообщения и категории, а также их содержимое.
Если, с другой стороны, вы настроили свой проект с помощью нескольких плагинов, вам придется разрабатывать их через интерфейсный проект или с помощью тех, которые предоставляются вашей Headless CMS. Например, если мы заботимся о SEO и поэтому используем Yoast SEO в WordPress, у нас будет SEO-плагин Field-Type в Storyblok, который поможет нам в переходе, но нам все равно придется разрабатывать нашу карту сайта во внешнем интерфейсе. с гидом, чтобы помочь нам.
В итоге вся тяжесть разработки ляжет на front-end проект, так как настройка Headless CMS не займет так много времени.
Но давайте прекратим болтать и давайте посмотрим на это!
Шаги по переносу нашего контента с WordPress на Storyblok
Миграция будет состоять из четырех шагов, от создания пространства в нашей новой безголовой CMS Storyblok до представления перенесенного контента в нашем внешнем проекте, который мы подробно рассмотрим ниже и в котором я оставлю вам ресурсы для сделать миграцию проще для вас.
Давайте начнем!
1. Создание пространства в Storyblok
Чтобы создать пространство в Storyblok, вам сначала нужно иметь учетную запись. Для этого вам нужно будет выбрать план, который подходит вам лучше всего.
Перейдите на страницу цен и начните с плана, который лучше всего соответствует вашим потребностям, или попробуйте бесплатный план для тестирования.
Создайте свою учетную запись, и вы сможете получить доступ к панели.
Выберите «Создать новое пространство» и приступим!
Пространство — это хранилище контента. Думайте об этом как о месте для хранения всего контента, связанного с одним проектом. Каждое пространство имеет свои собственные компоненты, источники данных, активы, среды, домены, соавторов и разрешения.
Потратьте некоторое время, чтобы изучить разделы на левой боковой панели. Начните с просмотра следующего:
- Content , это будет папка, в которой будет храниться контент, где маркетинговая команда будет проводить большую часть своего времени.
- Assets , где будут храниться все изображения, которые потом можно будет получить через сервис CDN, оптимизированные и любого размера.
- Компоненты , где вы будете создавать типы содержимого и вложенные компоненты .
- Настройки , раздел, в котором вы сможете настроить данные вашего пространства, а также языки вашего приложения, рабочие процессы, которым вы хотите, чтобы ваш контент следовал перед публикацией, разрешения пользователя и т. д. Предположим, что эта область будет один связан с ИТ-командой проекта.
Если вы все еще хотите изучить все параметры на панели инструментов, прежде чем погрузиться в миграцию, я рекомендую взглянуть на Understanding the UI by Storyblok.
Теперь, когда вы немного знакомы с экосистемой Storyblok, пришло время определить, как будет выглядеть содержимое нашего приложения.
2. Определение моделей
Чтобы перенести контент WordPress в Storyblok, следующим шагом будет создание схем, определяющих структуру данных WP, путем создания типов записей в пространстве Storyblok.
Давайте начнем со страниц и сообщений (основные типы сообщений на любом сайте WP), которые мы будем называть page
и post
в Storyblok.
Схема страниц в WP содержит поля: заголовок , слаг , избранное изображение , дата и контент .
Примечание . Чтобы просмотреть все поля, содержащиеся в типе сообщения, перейдите к схеме в справочниках по схемам WP REST API.
Что вам нужно знать, так это то, что по умолчанию любой тип контента в Storyblok будет иметь некоторые поля, уже определенные для вас, такие как « Имя », « Слаг », « Теги », « Дата первой публикации» и т. д.
Эти поля можно использовать для переноса контента из WP. Вам нужно будет только расширить его, добавив Featured_image и контент в Тип контента страницы.
Перейдите в раздел « Компоненты » в своем пространстве, нажмите на page
, созданную по умолчанию, удалите поле body и добавьте Featured_image как тип Assets > Images
и контент как Rich-text
.
Как только схема page
будет готова, давайте перейдем к post
. Для типа контента публикации необходимо включить дополнительную информацию, такую как Featured_image , excerpt , content и связи с другими типами , такими как Authors или Categories .
Поскольку у авторов и категорий также будет свой собственный контент, перейдите в раздел « Содержимое » на боковой панели и создайте пару папок с именами « авторы и категории» .
С каждой из папок должен быть связан тип содержимого по умолчанию. Для этого в разделе « Компоненты » создайте « Автор » и « Категория » в качестве новых типов контента, а затем свяжите тип контента относительно каждой папки, щелкнув три точки справа от папки и выбрав «Настройки».
Таким образом, в типе контента публикации вы можете добавить поле с одним или несколькими вариантами с исходными историями и указать папку, созданную для каждого поля:
- Авторы
При этом указывается папка, в которой находятсяauthors/
. - Категории
При этом указывается папка, в которой находятсяcategories/
.
Примечание . Если вы хотите узнать больше об этих отношениях, ознакомьтесь со статьей «Отношения между авторами и статьями».
Теперь, когда вы увидели, как создать несколько типов контента и как создать отношения между ними, вам нужно будет определить остальные модели, выполнив те же действия.
Добавление типа контента: глобальный
И вы спрашиваете себя, а как насчет контента, которым будут делиться все мои страницы? Нравится меню навигации, нижний колонтитул и другие общие элементы?
Не волнуйтесь, Storyblok уже подумал об этом и предлагает нам простое руководство по динамическому определению наших глобальных элементов. Он показывает нам, как создать глобальный тип контента и как использовать его в разделе « Контент ».
3. Перенос содержимого
Теперь пришло время начать перенос содержимого, которое вы сохранили. Чтобы получить доступ к содержимому WP, вам необходимо получить доступ к REST JSON API. Доступ к пути /wp-json
, если проект развернут, или ?rest_route=/
если локальный.
Если ни один из двух маршрутов не работает, проверьте HTML своей страницы на наличие ссылки в заголовке с rel="https://api.w.org/"
, как указано в руководстве по обнаружению WP, и получите правильный. .
<link rel="https://api.w.org/" href="https://localhost/your-site/index.php?rest_route=/">
Чтобы помочь нам во время миграции, разработчики Storyblok предоставили нам плагин, который сэкономит нам много работы. Этот плагин называется wordpress-importer, в нем можно определить эквивалентный тип контента в Storyblok для переносимого типа поста WP, и он подтолкнет его в наше пространство и перенесет изображения в наш раздел « Активы » для нас.
Примечание . Для использования этого скрипта требуется узел ≥14.0.0, поскольку он использует необязательную цепочку.
Создание сценария миграции
Первое, что нужно сделать, это клонировать репозиторий. Затем установите пакеты NPM с помощью npm install
или yarn
и создайте файл в корне проекта как migrateWPtoStoryblok.js . Чтобы запустить скрипт, вам нужен скрипт в package.json для его запуска, добавьте:
"migrate": "node ./migrateWPtoStoryblok.js"
Когда все будет готово, пора приступить к определению сценария в соответствии со спецификациями README. И, как видите, следующее, что потребуется, — это найти Space_id
и токен OAuth
для подключения к пространству Storyblok.
-
Space_id
находится в разделе « Настройки » на боковой панели, как только вы нажмете на него, вы увидите его справа. - Чтобы сгенерировать токен
OAuth
, вам нужно перейти в верхнюю часть боковой панели, щелкнуть маленькую стрелку рядом с логотипом Storyblok и перейти в раздел « Моя учетная запись» . Если мы прокрутим вниз, мы увидим раздел « Токены личного доступа », создадим один и скопируем его.
Когда вы получите оба секрета, вы можете добавить их в начало скрипта вместе с URL-адресом JSON API вашего проекта:
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 })
Как описано в предыдущих разделах, тип контента страницы в Storyblok эквивалентен типу поста на страницах WP. В приведенном ниже блоке кода вы увидите, где вам нужно указать каждый из них.
И после того, как тип публикации и тип контента определены, пришло время указать имя полей, используемых в этом типе объекта в WP, и эквивалентное имя в Storyblok в опции 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" } } ] })
Примечание . Чтобы миграция работала правильно, убедитесь, что постоянные ссылки выбраны по имени записи, а не так просто. В противном случае скрипт не создаст родительско-дочерние отношения между страницами.
В schema_mapping
вы можете определить несколько типов полей, это могут быть:
- Простое поле, например
title
. - Подсвойство поля, например, в данном случае URL-адрес изображения функции.
Примечание . Плагин сам заботится о переносе изображений в пространство Storyblok через соответствующий URL-адрес вlinks.wp:featuredmedia.0
. Поле перенесено во вложенный блок в Storyblok.
Представьте, что вы хотите создать компонент в Storyblok для определения форматированного текста вашего сайта, чтобы все типы записей, использующие его, имели одинаковый стиль и параметры.
Для этого вы можете использовать формат объекта и указать имя поля в модели Storyblok под свойством поля , имя компонента , который вы хотите сохранить в этом поле, и имя поля внутри компонента, в котором находится содержимое. будет перенесено.
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()
Страница типа записи
Теперь, когда вы знаете, как определить типы полей, для схемы страницы это будет выглядеть так, как показано в приведенном ниже блоке кода.
Плагин позаботится об отношениях родитель-потомок между страницами, создав папку в Storyblok под ярлыком родителя и связав родителя в качестве дома этой папки.
Кроме того, если поле содержимого содержит изображения , плагин также перенесет их для вас!
{ 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: '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", } }
Тип записи Категория
И как только схема для сообщений определена, имеет смысл определить схему для категорий, чтобы их можно было связать, как описано в предыдущем разделе.
Чтобы определить папку , содержащую их, как категории , а не как категорию, их имя по умолчанию, вы должны перейти к параметру « Постоянные ссылки » в панели администратора WordPress и изменить базовый параметр «Категории » на « categories
. Тогда поле с несколькими вариантами записей Post будет тем, которое имеет отношение к соответствующим категориям.
Примечание . Эти шаги аналогичны тем, которые необходимо выполнить для переноса авторов и связывания их со статьями.
{ 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", } }
Полный финальный сценарий
Приведенный ниже код будет результирующим сценарием миграции из проекта WP с базовыми типами в созданное нами пространство 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. Создайте интерфейсный проект
Теперь, когда содержимое уже сохранено на панели управления Storyblok, пришло время подключить интерфейсный проект к Storyblok.
Какой бы ни была ваша платформа или библиотека JS, Storyblok предоставляет клиент JavaScript, который поможет вам с интеграцией. Кроме того, если вы используете определенный фреймворк, вы найдете другие пакеты, которые облегчат вам работу, например, модуль storyblok-nuxt
в Nuxt.
Этот JavaScript API также будет включать мост между Storyblok и вашим интерфейсным приложением. Мост отвечает за связь через iframe с Storyblok, чтобы сообщить интерфейсу редактирования, какой компонент открывать, когда пользователь щелкает по нему.
Вот список руководств, которые вы можете найти на Storyblok для подключения вашего проекта Front-end.
Примечание . Если вы не найдете среди них свою технологию, не волнуйтесь, на веб-сайте Storyblok есть много других руководств, найдите свое в поисковой системе, и если вы не найдете ни одного, я рекомендую вам связаться с ними, и вы поможете еще многим людям!
- Следующий
- Гэтсби
- Вью
- Nuxt
- Угловой
- Стройный
- Эмбер
- AMP
5. Разместите свой интерфейсный проект и автоматизируйте развертывание
Когда ваш проект готов к запуску, вы выбираете хостинг-провайдера и связываете свой репозиторий для удобного развертывания, а затем задаете себе вопрос:
Как повторно развернуть мой статический сайт, если я опубликую запись на Storyblok?
Ответ очень прост: используя веб-хуки, предлагаемые Storyblok, и билд-хуки вашего хостинга.
Чтобы дать вам реальный пример, вы можете создать URL-адреса перехватчиков сборки в Netlify в разделе развертывания; URL-адрес, созданный для Storyblok в обработчиках сборки, будет отображаться в разделе « Настройки » → «Веб -перехватчики» → « История опубликована и неопубликована » в пространстве Storyblok.
Руководства и инструменты, которые мы использовали во время миграции
Давайте повторим ссылки, которые помогли при переносе контента, и те, которые помогли понять функционирование REST API и безголовой CMS, на которую вы переходите.
Требуется документация WP REST API
ОТДЫХА API
- Справочник по конечной точке разработчика REST API
- Использование REST-API
- Обнаружение API и его маршрута
Схемы
- Ссылка на схему страницы
- Ссылка на схему публикации
- Ссылка на схему категорий
Переход на Storyblok
Общая информация
- Официальный сайт Сториблока
- Сториблок Цены и планы
Документация
- Понимание пользовательского интерфейса
- Структуры контента
- Настройка структуры контента блога в Storyblok
Глобальные компоненты
- Как создать навигацию по меню шапки сайта с помощью Storyblok
- Сюжетный мост V2
Связанные с SEO
- Как сгенерировать карту сайта a445r с помощью безголовой CMS?
- https://www.storyblok.com/apps/seo
Веб-хуки и билд-хуки
- Все о вебхуках
- Как использовать вебхуки Storyblok
- Хуки сборки хостинга — пример Netlify
Скрипты и пакеты
- Универсальный SDK JavaScript для API Storyblok: https://github.com/storyblok/storyblok-js-client
- Помощник по миграции WP на Storyblok: https://github.com/storyblok/wordpress-importer
Джемстек
- Веб-сайт Jamstack
- Список генераторов статических сайтов для сайтов Jamstack
Заключение
После прочтения этой статьи у вас будет все, что вам нужно, чтобы понять, почему безголовая установка улучшит ваш проект, как перейти с вашего проекта WordPress на безголовую CMS, такую как Storyblok, и как продолжать улучшать и расширять свой проект.
Как вы видели, возможности установки без головы безграничны . 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?