Общие практики, болевые точки и вещи, на которые следует обратить внимание при создании веб-сайта WordPress без заголовка.

Если вы никогда раньше не слышали о WordPress, то я уверен, что вы жили под скалой довольно долгое время. WordPress на сегодняшний день является самой популярной системой управления контентом (CMS) в мире. Авторы контента любят тот факт, что он не мешает вам сосредоточиться на написании. Разработчикам нравится его расширяемость и свобода в том, что вы хотите с ним делать.

С появлением новых интерфейсных технологий традиционное программное обеспечение CMS может быть ограничивающим. Плагины часто добавляют много лишнего, и вы ограничены тем, что могут дать вам система тем и ваши плагины. Вот почему «безголовые CMS» в последнее время стали повсеместным увлечением.

В отличие от традиционной монолитной CMS, автономная CMS отделяет логику представления от самой себя. CMS действует исключительно как панель управления контентом, обслуживаемая через REST API.

Это является прорывом как для разработчиков, так и для авторов контента. Авторы контента могут придерживаться знакомого интерфейса WordPress. Разработчики могут использовать его API для обслуживания контента на любом устройстве, которое они хотят.

Только по этой причине мы решили построить наш новый блог именно так.

Архитектура

В начале нашего блога находится современное веб-приложение, созданное с использованием Next.js. Это минималистичный фреймворк для серверных приложений React, созданный хорошими людьми из ZEIT.

Веб-сайт Next.js извлекает весь контент из автономного экземпляра WordPress. Гибкость WordPress позволяет ему быть как монолитным, так и безголовым. В безголовой архитектуре WordPress использует встроенный REST API, который любой клиент может использовать для получения контента.

Вся установка основана на этом стартовом комплекте для безголового WordPress, созданном Postlight. В комплект входят батарейки, темы, плагины и даже полностью работающий интерфейс Next.js для запуска вашего сайта. Он также включает удобные инструменты для автоматизации большей части нашего рабочего процесса и сосредоточения внимания на нашем коде.

Настройка темы

«А теперь подождите, - спросите вы, - если наш WordPress безголовый, тогда зачем нам тема?»

Прежде всего, нам нужно будет зарегистрировать некоторые функции в нашей настройке WordPress. Один из них перенаправляет каждый запрос в конечную точку REST API, поскольку мы не используем WordPress для рендеринга нашей страницы.

А во-вторых, нам нужна настраиваемая конечная точка REST API для получения сообщения по его слагу, поскольку мы передадим это из внешнего интерфейса в качестве аргумента. WordPress имеет специальный API для настройки пользовательских маршрутов REST API в нашей теме. Чтобы узнать больше об этих API, ознакомьтесь с этим руководством.

Теперь попробуйте открыть свой сайт WordPress в браузере. Вы должны увидеть, что теперь все перенаправлено на REST API.

Плагины

WordPress уже готовится к редактированию нового поколения под названием Gutenberg. Если вы хотите попробовать его сейчас, это можно сделать по желанию, установив подключаемый модуль. Однако Гутенберг все еще находится в зачаточном состоянии. Некоторые функции, которые нам нужны, такие как размещение блоков в API, все еще находятся в разработке.

Поэтому для целей нашего блога я откладываю это в сторону. Однако это не значит, что я не пробовал Гутенберга. Я разветвил стартер Postlight и преобразовал его для использования Gutenberg.

Самое близкое к Гутенбергу, что доступно, - Расширенные настраиваемые поля. Мы используем это для управления настраиваемыми полями для добавления в наши сообщения. Например, добавление дополнительного поля для выдержек из сообщений, а также избранных изображений в сообщениях.

Чтобы иметь возможность использовать поля ACF и настраиваемые меню в нашем интерфейсе, нам необходимо предоставить их в нашем REST API.

Для ACF мы используем плагин ACF to WP-API. Он вообще не требует настройки и помещает настраиваемые поля в ваш ответ API публикации под ключом _acf.

Для наших меню wp-rest-api-v2-menus позволяет нам отображать меню как конечные точки WP-API. Благодаря этому мы можем создавать настраиваемые меню сайта для нашего интерфейса. Чтобы получить доступ к этому меню из REST API, нам нужно зарегистрировать некоторые места навигационного меню. Поместите в functions.php своей темы следующее:

Чтобы получить доступ к этому меню, вызовите API, созданный плагином, добавив ярлык меню. Например: /wp-json/menus/v1/menus/header-menu.

Интерфейс

В Kata.ai мы большие поклонники React. В мире JavaScript он уже не нуждается в дополнительном представлении. Есть много причин, по которым это один из самых популярных фреймворков JavaScript в мире. Специально для одностраничных приложений.

Но сайты с большим количеством контента, такие как блоги, полагаются на SEO, поэтому рендеринг на стороне сервера по-прежнему остается актуальным. Некоторые популярные решения для рендеринга на стороне сервера включают Razzle и Next.js, но Next.js выделяется среди остальных.

Next.js предоставляет чистый, минималистичный API, позволяющий быстро приступить к работе. По умолчанию он предоставляет next командную строку, в которой запускается предварительно настроенный веб-сервер. Но вы также можете настроить собственный сервер со своими собственными обработчиками запросов и схемами маршрутизации, если хотите. Next.js предоставляет серверные API, которые позволяют нам это делать.

В этом примере мы используем Express для следующих действий:

  • Создание обработчиков запросов для некоторых пользовательских путей маршрута
  • Создайте резервный маршрут для перенаправления всех запросов за пределами определенного маршрута в Next.js
  • Запустите наш слушатель сервера.

Вот как вы настраиваете собственный сервер Next.js. Довольно круто, правда? Вы даже можете заменить Express любой другой серверной библиотекой, какой захотите, например, koa или hapi.

Получение контента + getInitialProps

В Next.js каждая страница имеет свой собственный файл в каталоге /pages. По умолчанию он обслуживается относительно своего пути на веб-сервере. Например, чтобы создать страницу для сообщений, мы создаем файлы post.jsx и page.jsx внутри каталога pages/. Когда мы запускаем сервер Next.js, мы можем получить к нему доступ из /post и /page соответственно.

По умолчанию Next.js использует параметры запроса для передачи данных на страницу. Но поскольку мы настроили собственный обработчик сервера для нашего приложения Next.js, мы можем переопределить его, чтобы использовать параметры маршрута.

WordPress имеет два встроенных типа сообщений: post и page. На нашем внешнем сервере мы добавим для них маршруты непосредственно перед нашим резервным обработчиком. Мы создаем маршрут, который принимает параметр slug для них обоих. Это, в свою очередь, отображает страницу, которую вы указали при посещении этого маршрута.

В этом фрагменте кода функция render() принимает ваш объект запроса и ответа, а также фактическую страницу относительно каталога pages /, а также некоторые параметры запроса.

Затем внутри компонента мы позволяем getInitialProps() делать всю тяжелую работу. Вы можете использовать это, чтобы получить все, что угодно, из API и предварительно отрендерить их на своей странице, это очень просто.

Обработка поиска

Реализовать поиск WordPress в нашем веб-интерфейсе Next.js очень просто. Теперь мы можем использовать схему маршрутизации Next.js по умолчанию, которая основана на параметрах запроса.

Например, предположим, что у нас есть такой компонент панели поиска:

Когда форма отправлена, мы можем просто использовать next/router для перенаправления пользователей на страницу поиска и передать запрос getInitialProps().

Мы можем попробовать нашу новую страницу поиска! Введите что-нибудь в поле поиска и отправьте. Если вас перенаправят на страницу поиска, все в порядке!

А как насчет превью постов?

Одна из проблем WordPress без заголовка заключается в том, что по умолчанию WordPress создает собственную страницу предварительного просмотра. А мы этого не хотим.

Интересно, что мы можем создать в нашей теме ссылку на настраиваемую кнопку «Предварительный просмотр», используя фильтр preview_post_link. Нам нужно настроить его в functions.php нашей темы WordPress. Это изменит наш URL-адрес предварительного просмотра на тот, который определен в этом фильтре.

Здесь измените ссылку на путь /_preview, который будет содержать идентификатор предварительно просмотренного сообщения, а также wpnonce. Это необходимо для аутентификации. Он также установит домен предварительного просмотра в зависимости от того, включен ли у вас WP_DEBUG или нет.

Затем на нашем сервере Next.js мы делаем то же, что и все остальное, регистрируем маршрут и получаем сообщение на странице. Но вместо использования getInitialProps() мы используем стандартный componentDidMount() жизненный цикл. Нам нужно это использовать, потому что wpnonce аутентификация зависит от файлов cookie браузера.

Поэтому, когда мы нажимаем кнопку «Предварительный просмотр» в редакторе WordPress, теперь выполняется перенаправление в приложение Next.js.

Что дальше?

Если такие вещи пощекотали ваше воображение, вам стоит попробовать безголовый WordPress. Если вы хотите пойти дальше, вы также можете использовать новые функции WordPress, такие как Gutenberg. Или попробуйте современные инструменты для запросов к API, такие как GraphQL, благодаря плагину wp-graphql.

Headless CMS - это новая парадигма в веб-разработке, но ее приложения безграничны. В мире современного Интернета, основанном на API, управление контентом переходит в новую эру. С помощью безголовой CMS вы можете публиковать свой контент и использовать его API для получения контента на любой платформе, о которой вы только можете мечтать. Будь то ваш статический сайт, мобильное приложение или даже ваш чат-бот.

И наконец, несмотря на свой возраст, WordPress по-прежнему остается очень гибкой CMS. Безголовая CMS с WordPress стоит попробовать, и преимущества, которые мы получаем, перевешивают риски и болевые точки, с которыми мы столкнулись.