Насколько нишевым является автономный WordPress?

Интересно, где приземлится автономный WordPress. И под «автономный» я подразумеваю только использование администратора WordPress и создание сайта, ориентированного на пользователя, с помощью WordPress REST API, а не традиционной структуры тем WordPress.

Есть ли спрос?

Безусловно, спрос на это есть. Я знаю множество людей, которые этим занимаются. Например, у Gatsby есть плагин gatsby-source-wordpress, который позволяет вам получать контент с сайта WordPress таким образом, чтобы использовать WordPress REST API и кэшировать его как GraphQL для использования на сайте Gatsby на основе React. В этом месяце его скачали 59 тысяч раз, а на момент написания статьи - 851 тысяч раз. Это здоровый кусок использования для одной конкретной технологии создания сайтов. Буквально, каждое использование gatsby-source-wordpress использует автономный WordPress — это именно то, что он есть/делает.

И это только одна вещь, она не учитывает целые компании и продукты, посвященные этой идее.

Что такое автономное улучшение?

Интеграция с Гэтсби дает веские основания для того, чтобы кто-то рассматривал автономный сайт WordPress. Я доберусь до этого.

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

Настоящая причина, по которой я думаю, люди тянутся к серверной части WordPress для интерфейса, основанного на Gatsby, по сути, заключается в следующем: им нравится React. Им нравится строить вещи из компонентов. Им нравится быстрый переход между страницами. Им нравится иметь возможность размещать вещи где-нибудь в Jamstack-y со всеми хорошими превью для разработчиков и тому подобным. Им нравится горячая перезагрузка модуля. Им нравится Prettier и JSX. Им это просто нравится, и я их не виню. Когда вам нравится такой опыт разработчика, возвращение к созданию шаблонов PHP, когда требуется ручное обновление браузера и поддержание какого-то ручного процесса сборки, не совсем заманчиво.

Frontity - еще один продукт, который хочет усовершенствовать React + WordPress.

Но станет ли автономный WordPress более популярным, чем традиционная тематическая модель WordPress, основанная на шаблонах PHP, которые соответствуют явной структуре? Неа. Что ж, возможно, так и было бы, если бы WordPress сам поддерживал эту идею и предлагал рекомендации, обучение и документацию, которые облегчат разработчикам принятие этого подхода. Я бы согласился, если бы WordPress сказал, что автономная архитектура - это новый курс. Но все это неправда. Следовательно, в какой-то степени это нишевая вещь.

Почему автономность является узконапрвленной?

WP Engine - это большой хост WordPress, в котором есть целая штука под названием Atlas. И эти усилия определенно выглядят так, будто они серьезно относятся к этой нише рынка. Я не уверен на 100%, что такое Атлас, но это похоже на панель инструментов для раскрутки сайтов с интересным видом кода в виде конфигурации. Один из слонов в комнате с автономным WordPress состоит в том, что теперь у вас есть два веб-сайта, с которыми нужно иметь дело. У вас есть место, где вы размещаете и используете WordPress, и где бы вы ни размещали и не запускали сайт, который использует API WordPress. Может быть, это как-то сближает эти две вещи. Развертывание из Git-коммитов привлекательно, и в наши дни я считаю, что это хорошая ставка для современного хостинга.

Еще одна причина, по которой люди предпочитают автономный WordPress, заключается в том, что конечный результат может быть статическим, как в случае предварительно сгенерированных HTML-страниц. Это означает, что сервер вашего веб-сайта может иметь высокую степень CDN, поскольку для загрузки доступны буквально только статические ресурсы. Нет PHP или базы данных для рендеринга на стороне сервера, который может быть медленным (и, честно говоря, решаемым), поскольку он добавляет процесс перед рендерингом.

Каким «способом WordPress» обойтись без автономности?

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

Вот что делает Strattic. Они создают для вас сайт WordPress, который считают постановкой. Вы делаете там свою работу с WordPress, а затем используете их систему публикации, чтобы запустить статическую версию вашего сайта в производство. Это убедительно, потому что он решает то, чего не делает другое использование автономного WordPress: просто делает что-то так же, как WordPress.

Например, пользовательские блоки или плагины WordPress могут создавать выходные данные, содержащие не только пользовательский HTML, но также CSS и JavaScript. Представьте себе блок или плагин «карусель». Эта карусель не сработает, если все, что вы делаете, это захватываете содержимое публикации из API и переносите его на страницу. Вам либо нужно будет извлечь CSS и JavaScript откуда-нибудь и включить их, либо каким-то образом просто знать, что вы больше так не делаете. Вы можете каким-то образом прикрепить изображения как метаданные, вытащить их на стороне клиента и сделать свою собственную реализацию карусели. Со Strattic теоретически он будет работать, поскольку HTML, CSS и JavaScript все еще присутствуют на статическом сайте. Но примечательно, что у вас нет PHP, поэтому Strattic пришлось вручную создавать интеграции форм, они используют Algolia на стороне клиента для поиска, Disqus для комментариев и т. д., потому что серверный язык недоступен.

Shifter - еще один игрок. Это похоже на Strattic, где вы работаете над своим сайтом в админке WordPress, а затем публикуете его на статическом сайте. Я считаю, что Shifter запускет ваш сайт WordPress, когда он не используется, что имеет смысл, поскольку вывод статичен и нет причин, по которым сервер с PHP и MySQL должен работать. В качестве альтернативы у Shifter есть установка автономного WordPress, которая, по-видимому, все время остается развернутой для внешнего использования API.

Приятно думать обо всем этом

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