Comments 28
Первая ссылка в гугле по запросу Headless CMS ведет на сайт со списком таких CMS.
У вас есть опыт использования разных CMS? Что можно выбрать для наиболее гладкого перехода с Wordpress?
Основной затык в SSG, и преимущество Wordpress, в том, что добавить новую статью на вордпрессе достаточно легко, затем ошибиться и подправить с десяток раз. В случае с SSG — это каждый раз деплой, или установка preview-mode, в котором надо разбираться. А человек, которые обычно ответственен за добавление новых статей в вордпрессе — не шибко хочет разбираться в нюансах SSG.
При этом, стоимость Contenful CMS "для бизнеса" начинается от 879 долларов за месяц, довольно неподъемная сумма.
Боюсь, что опыт перехода с WordPress у меня только начнет появляться в ближайшие пару месяцев, после того как допишу курс.
Я попробую использовать Ghost.io для перехода с WordPress, потому что (1) он бесплатный, (2) разворачивается в 1 Docker контейнер, (3) любое событие в системе работает через hook, а значит можно встроиться в любой процесс, (4) куча инструкций на стыке Gatsby.js + Ghost.
Полноценное удобство деплоя SSG, возможно только в случае использования современных систем типа Netlify / Vercel, потому что они берут на себя всю работу по CI / CD.
Про preview-mode, да, придется применить свое решение: в случае с Ghost.io + Gatsby.js, можно запустить на сервере отдельный Gastby.js в режиме development, со своим доменом и прописать путь не до стандартного API, а до админского, который будет отдавать все draft («черновики»). Тогда редактор, при написании draft статьи сможет просматривать в режиме preview. Думаю, что существуют еще более простые пути решения вопроса, но это первое, что пришло в голову.
Сейчас я использую Markdown + Github + Vercel, что позволяет в отдельно репозитории делать ветку со статьей, править ее сколько хочу прямо в интерфейсе Github, каждая правка сохраняется как Pull Request и автоматически деплоится через Vercel с отдельным URL. Так что всей командой можем спокойно редактировать.
Про «человек, которые обычно ответственен за добавление новых статей в вордпрессе» – да, такая проблема имеется, потому что мало кто в рускоязычном сегменте использовал SSG + HCMS, поэтому придется дать людям время на привыкание.
Я попробую использовать Ghost.io для перехода с WordPress, потому что (1) он бесплатный, (2) разворачивается в 1 Docker контейнер, (3) любое событие в системе работает через hook, а значит можно встроиться в любой процесс, (4) куча инструкций на стыке Gatsby.js + Ghost.
Полноценное удобство деплоя SSG, возможно только в случае использования современных систем типа Netlify / Vercel, потому что они берут на себя всю работу по CI / CD.
Про preview-mode, да, придется применить свое решение: в случае с Ghost.io + Gatsby.js, можно запустить на сервере отдельный Gastby.js в режиме development, со своим доменом и прописать путь не до стандартного API, а до админского, который будет отдавать все draft («черновики»). Тогда редактор, при написании draft статьи сможет просматривать в режиме preview. Думаю, что существуют еще более простые пути решения вопроса, но это первое, что пришло в голову.
Сейчас я использую Markdown + Github + Vercel, что позволяет в отдельно репозитории делать ветку со статьей, править ее сколько хочу прямо в интерфейсе Github, каждая правка сохраняется как Pull Request и автоматически деплоится через Vercel с отдельным URL. Так что всей командой можем спокойно редактировать.
Про «человек, которые обычно ответственен за добавление новых статей в вордпрессе» – да, такая проблема имеется, потому что мало кто в рускоязычном сегменте использовал SSG + HCMS, поэтому придется дать людям время на привыкание.
Я предпочитаю использовать strapi.io в связке с Gatsby.js. Strapi предоставляет возможность гибкого формирования контента в довольно удобном интерфейсе и управлять доступом к нему через GraphQL API. А у Gatsby есть плагин для интеграции (gatsby-source-strapi). Всё это можно публиковать на Vercel или Git(Hu|La)b Pages. У Vercel есть что-то типа AWS Lambda. И всё это бесплатно.
Использую Gatsby с Contentful (бесплатная версия полностью хватает) и Prismic (нравятся слайсы и бета функция integration fields).
Был проект на Gatsby + Wordpress с плагинт WPGraphQL, но после того как взломали из-за какого-то плагина, пришлось переность на Contentful.
Для форм использовал getform.io
Для e-commerce выбор остановил на Shopify, лайт версия за 9$, но пока dev аккаунт.
На счет Ghost.io выглядит не плохо, только не хочу опять сам что-то хостить, а платная версия за $29 в месяц пока не нужна.
Есть еще хороший инструмент Storyblocks, советую посмотреть.
Был проект на Gatsby + Wordpress с плагинт WPGraphQL, но после того как взломали из-за какого-то плагина, пришлось переность на Contentful.
Для форм использовал getform.io
Для e-commerce выбор остановил на Shopify, лайт версия за 9$, но пока dev аккаунт.
На счет Ghost.io выглядит не плохо, только не хочу опять сам что-то хостить, а платная версия за $29 в месяц пока не нужна.
Есть еще хороший инструмент Storyblocks, советую посмотреть.
Есть некоторые решения которые превращают SSG в «программу» по сути это SSG завернутый в Electron. Одно из таких решений — Publii по идее позволяет сделать статический бложек даже секретарше.
Проект достаточно давний, но руки у меня до него дошли только в этом году, попробовал перетянуть блог на него — в целом достаточно удобно.
Сайт можно разместить как на обычном шаред хостинге, через выгрузку по FTP, так и на тех же Github, Gitlab и прочих git-хостингах.
Проект достаточно давний, но руки у меня до него дошли только в этом году, попробовал перетянуть блог на него — в целом достаточно удобно.
Сайт можно разместить как на обычном шаред хостинге, через выгрузку по FTP, так и на тех же Github, Gitlab и прочих git-хостингах.
У нас 10+ лет как работает самописная CMS, генерирующая статику (после того, как придя к клиенту в офис, мне потребовалось 20 минут на то, чтобы найти, как на тогдашней джумле подправить пару слов на главной странице). Но вот как-то с магазинами я совсем не понял, как статикой можно обойтись. Одно только ведение корзины уже обязывает делать обработку обращений на серваке.
Побольше можно почитать, например, здесь.
Cвоими словами скажу так: у вас есть SSG, например, Gatsby.js. Он дает вам возможность писать статический и динамический контент на React. То есть, все что может быть статическим (страницы товаров, каталоги и т.д), будет выгружаться статически, а логику и отображение динамической части (корзина, поиск и т.д) вы спокойно пишете на React.
Соответственно, для реализации корзины вы можете:
В самом простом случае, вы реализуете логику (как показано здесь) через React Context / Redux + любое хранилище на фронте (localstorage, indexdb, etc.), а оплату можно делать через Stripe и подобные сервисы, где для формирования счета достаточно отправить метаданные о цене и товарах прямо с фронта.
Если нужно что-то сложнее, то подключаем Firebase / Hasura и имеем CRUD с фронта, с корзиной на backend.
Если нужно еще сложнее, то добавляем к Firebase / Hasura облачные лямбды (FaaS).
Если логика еще сложнее, то спокойно пишите свой серверный код и общаетесь с умным фронтом на React.
Я правильно понял и ответил на вопрос?
Cвоими словами скажу так: у вас есть SSG, например, Gatsby.js. Он дает вам возможность писать статический и динамический контент на React. То есть, все что может быть статическим (страницы товаров, каталоги и т.д), будет выгружаться статически, а логику и отображение динамической части (корзина, поиск и т.д) вы спокойно пишете на React.
Соответственно, для реализации корзины вы можете:
В самом простом случае, вы реализуете логику (как показано здесь) через React Context / Redux + любое хранилище на фронте (localstorage, indexdb, etc.), а оплату можно делать через Stripe и подобные сервисы, где для формирования счета достаточно отправить метаданные о цене и товарах прямо с фронта.
Если нужно что-то сложнее, то подключаем Firebase / Hasura и имеем CRUD с фронта, с корзиной на backend.
Если нужно еще сложнее, то добавляем к Firebase / Hasura облачные лямбды (FaaS).
Если логика еще сложнее, то спокойно пишите свой серверный код и общаетесь с умным фронтом на React.
Я правильно понял и ответил на вопрос?
В таком случае можно подключить еще одно *aaS решение с корзиной. С другой стороны, используя next.js никто не мешает создать отдельный раздел с таким же функционалом.
Наверняка подобные CMS поддерживают возможность user-generated контента, типа комментариев.
Зачем огород городить? Если нужна статика, учите HTML+CSS, пишите код в любом удобном «блокноте» и будет вам счастье. Я в недавно далёком 2004 году писал сайты на виндовском блокноте, таблицами, фреймами, картами изображений и прочими мастдаями той эпохи. CSS тогда был куц и скуден и дивами писать было в новинку. Хостились тогда у местных провов, у которых брали диалуп-интернет со скоростью 32 килобит/сек. Шла борьба за каждый байт веса странички — писали код без пробелов и скупо оставляли в нем краткие комментарии. И сайты работали.
Так что, если вам нужна таки статика, то вам нужна старая школа верстки. Вместо CMS можете использовать Dreamweaver — визуальный HTML-редактор компании Adobe. Тот же блокнот, только с фичами и наворотами.
Так что, если вам нужна таки статика, то вам нужна старая школа верстки. Вместо CMS можете использовать Dreamweaver — визуальный HTML-редактор компании Adobe. Тот же блокнот, только с фичами и наворотами.
Зачем огород городить?
писали код без пробелов и скупо оставляли в нем краткие комментарии.
Кажется, вы сами же и ответили на свой вопрос.
Да, я тоже там был и помню, когда Dreamweaver был какой-то магической штукой, которая за тебя много чего делала. Но сейчас всё немного по другому.
Предположим, есть сайт из 100 HTML файлов и везде нужно изменить какой-то блок. Сейчас этот блок — это один React компонент, который лежит в отдельном файле и включается в сборку с помощью описываемых инструментов. Кроме того они делают намного больше полезного чем просто сборка.
А вопрос скорости интернета актуален и сейчас. Доля мобильного трафика очень высока и местами его качество оставляет желать лучшего.
Зачем вы писали комментарии в HTML? неужели кому-то потом что-то может быть непонятно?
Вроде современно и круто, но всё равно остается какое-то послевкусие из нулевых, бесплатный nm.ru, ssi инклуды. Примерно такое же ощущение было в свое время от key-value бд, которые вдруг (после годов триумфального шествия сложных sql баз данных) стали популярными.
Для всего свой инструмент. Описываемые решения, как ни странно, больше нужны для удовлетворения требований поисковиков (SEO) и максимального улучшения пользовательского опыта, что в последнее время близко. Страницы статичны, быстро отдаются серверами, пользователи видят страницу мгновенно со всеми зависимостями в теле документа (разметка, critical CSS, минимизированные превьюшки изображений в виде base64). При навигации по сайту загружается тот минимум, который необходим для отображения следующей страницы. И даже при определенной настройке этот минимум загружается, когда пользователь только навел на ссылку. Похоже, что этот подход уже устаканился и его уже всё чаще и чаще используют большие компании.
Описываемые решения, как ни странно, больше нужны для удовлетворения требований поисковиков (SEO) и максимального улучшения пользовательского опыта, что в последнее время близкоЭто, мягко говоря, спорно.
1) Поисковики сейчас хотя и видят подгружаемый контент, но все же учитывают в основном тот, что уже есть в хтмл странице. Поэтому подгружая часть контента позже — Вы не только лишаете сайт части контента с точки зрения поисковика, но и занимаетесь отчасти клоакингом.
2) Пользователь приходит не за каркасом, а за контентом. Но в такой системе каркас встраивается в тело (критикал цсс) что бы не тормозило и было сразу готово, а контент выкидывается за борт (подгружаясь потом как-нибудь) что бы… прямо противоположное:) И это умножается когда подобное реализует в нагруженных проектах, контент загружается мультизапросами, иногда грузится неадекватно долго или не прогружается вообще. При этом учитывая что размер контента не всегда можно спрогнозировать в критической верстке — по мере подгрузки контента страница начинает прыгать.
Похоже, что этот подход уже устаканился и его уже всё чаще и чаще используют большие компании.Используют, несомненно. На многих сайтах приходится ждать прогрузки комментариев, допустим. Или боковых блоков. А иногда они не загружаются и приходится перезагружать всю страницу. Или вот интернет магазин — вроде ты залогинился и все ок, а корзина пустая. Не потому что пустая, а потому что не подгрузилась. Но юзеру думает что пустая.
А для поисковиков отдается пустая с точки зрения контента страница, поэтому в превью в гугле вместо прежних коротких текстов иногда видишь абсолютно пустую шнягу или кусок навигации с копирайтами. Удобно, чё.
На самом деле это подход это шаг назад сделанный как попытка замаскировать проблему быстрой загрузки, но не решить ее. Вместо добавления пары серверов и оптимизации кода, что бы все грузилось за 0.5 секунды вместо прежних 2… делают прогрузку каркаса за 0.1 секунды и радостно рапортуют об успехе, а то что контент потом еще 4 секунды будет весь грузиться таращя страницу и не всегда прогружаясь — да кого это волнует, ведь главное это использование модного подхода. Печально.
UFO just landed and posted this here
довольно плотно занимаюсь разработкой на WP.
есть у WP много минусов, но плюсы (для меня и клиентов) пока перевешивают
все то, что указано в статье как «минусы WP» в равной мере подходит и для статики.
предложенный подход для кастомизации темы «понатыкать кучу !important» в корне не верен, несет кучу проблем. Как вы сами уже и заметили.
Не вижу проблемы в «начать пилить самому». Для SSG при таком подходе нужен будет ровно такой же объем работ. Разве что вместо пхп будет другой язык
Ну, ровно то же самое можно сказать при первом знакомстве с WP — он устроен так, что можно легко и удобно добавить нужные плагины.
На практике же все не так радужно. Список ваших багов вы в статье привели. С SSG, уверяю, проблемы тоже есть.
Есть плагины, которые умеют перегонять WP в статику.
Можно сгенерированное позже класть куда угодно.
тут да, взломать WP с старыми плагинами будет проще, чем облачный хостинг.
нет, разницы не вижу. Если WP + плагин дает ровно тот же функционал, то в чем разница?
Стоит еще учитывать, что некоторые фичи WP вначале разрабатываются как отельные плагины, позже, если они востребованы, добавляются в ядро
выше писал, что в статику WP перегоняется на раз-два. Даже банально, без плагинов — wget + развернутый локально сайт.
Вообще, общее впечатление от статьи схоже с чтением отзыва только только приехавшего эмигранта — все вокруг нравится, минусы идут в плюсы и тп.
Не, технология отличная, но плюсов в переходе уже существующего проекта (так, чтоб они перевесили время на переход или чтоб время на переход вышло меньше, чем время на устранение проблем на текущей платформе) найти не смог.
есть у WP много минусов, но плюсы (для меня и клиентов) пока перевешивают
все то, что указано в статье как «минусы WP» в равной мере подходит и для статики.
V. Дизайн
предложенный подход для кастомизации темы «понатыкать кучу !important» в корне не верен, несет кучу проблем. Как вы сами уже и заметили.
2) Начать пилить Тему самому. Но для этого придется использовать PHP, CSS, HTML и рендеринг шаблонов на сервере.
Не вижу проблемы в «начать пилить самому». Для SSG при таком подходе нужен будет ровно такой же объем работ. Разве что вместо пхп будет другой язык
Во-первых, SSG и HCMS устроены так, что их легко и удобно интегрировать с любой системой, которая имеет API.
Ну, ровно то же самое можно сказать при первом знакомстве с WP — он устроен так, что можно легко и удобно добавить нужные плагины.
На практике же все не так радужно. Список ваших багов вы в статье привели. С SSG, уверяю, проблемы тоже есть.
А теперь просто киллер-фича: SSG позволяет выгрузить весь контент в заранее собранные HTML файлы минимального размера, что уже дает максимальную скорость показу сайта клиенту, так?
Есть плагины, которые умеют перегонять WP в статику.
Можно сгенерированное позже класть куда угодно.
IX. Безопасность
тут да, взломать WP с старыми плагинами будет проще, чем облачный хостинг.
Но, вы понимаете насколько большая разница качества и удобства подобного функционала? Когда это не “дополнительная функция с плагином”, а основной механизм технологии?
нет, разницы не вижу. Если WP + плагин дает ровно тот же функционал, то в чем разница?
Стоит еще учитывать, что некоторые фичи WP вначале разрабатываются как отельные плагины, позже, если они востребованы, добавляются в ядро
XI. Условная бесплатность
выше писал, что в статику WP перегоняется на раз-два. Даже банально, без плагинов — wget + развернутый локально сайт.
Вообще, общее впечатление от статьи схоже с чтением отзыва только только приехавшего эмигранта — все вокруг нравится, минусы идут в плюсы и тп.
Не, технология отличная, но плюсов в переходе уже существующего проекта (так, чтоб они перевесили время на переход или чтоб время на переход вышло меньше, чем время на устранение проблем на текущей платформе) найти не смог.
предложенный подход для кастомизации темы «понатыкать кучу !important» в корне не верен, несет кучу проблем. Как вы сами уже и заметили.
Абсолютно согласен, но проблема в чем: я использую тему Salient и некоторые свойства, кастомизацию которых они сами не дали, мне приходится переписывать через !important, потому что внутри самой темы они написаны через !importnant…
И можно сказать: «Не используй noname темы» – но это одна из самых знаменитых тем WP вот пруфы: 100 000 покупок по 60$ и 5 звезд рейтинга.
Можно сказать: «Так поищи другую, нормальную тему, где нет в коде !important» – но так можно искать вечность.
Короче, лично мне надо делать тему с нуля.
Не вижу проблемы в «начать пилить самому». Для SSG при таком подходе нужен будет ровно такой же объем работ. Разве что вместо пхп будет другой язык
Именно об этом я и говорю: вы – PHP разработчик со стажем на WordPress, я – НЕ PHP разработчик со стажем на WordPress, и не хочу тратить время на его глубокое изучение, как и вспоминать PHP.
Поэтому для меня я вижу проблему начать пилить тему самому.
Ну, ровно то же самое можно сказать при первом знакомстве с WP — он устроен так, что можно легко и удобно добавить нужные плагины.
Через PHP, а я его не хочу использовать.
С SSG, уверяю, проблемы тоже есть.
Абсолютно согласен.
Есть плагины, которые умеют перегонять WP в статику.
Можно сгенерированное позже класть куда угодно.
Об этом я написал в статье и привел ссылку (даже с видео). Но и описал, что с этим тоже есть проблемы (например, не все WP плагины нормально работают в статике).
нет, разницы не вижу. Если WP + плагин дает ровно тот же функционал, то в чем разница?
Этот абзац посвящен удобству использования API.
Все ли плагины WP адаптируются под API? Нет.
Все ли плагины HCMS адаптируются под API? Да.
Вот и основная разница.
выше писал, что в статику WP перегоняется на раз-два. Даже банально, без плагинов — wget + развернутый локально сайт.
В статье и выше написал в чем будут проблемы с этим.
Не, технология отличная, но плюсов в переходе уже существующего проекта (так, чтоб они перевесили время на переход или чтоб время на переход вышло меньше, чем время на устранение проблем на текущей платформе) найти не смог.
Да, я отлично это понимаю и рад, что вы делаете здравый и правильный для себя выбор. Думаю, что если бы у меня был большой опыт с WP, я бы тоже без ооочень серьезной причины не стал бы переезжать.
как вот это
соотносится с вот этим?
что явно намекает — что статья для людей с опытом работы с WP
повторюсь, любой довод из статьи либо не верен, либо исходит из негативного/неправильного личного опыта автора, либо в равной мере относится к WP/JAM
это проблема конкретно этой темы, к WP никак не относится
если взять готовую верстку с кучей !important и попробовать ее использовать на статическом сайте, попутно пытаясь что-то кастомизировать, — вылезут ровно те же проблемы.
к самой технологии/движку это вообще никаким боком
Если вы не знаете php, это не значит, что нужно автоматом всем уйти с php движка. В идеале, еще бы и перестать агитировать всех уходить с php, но это утопично.
может это и есть основная проблема?
а, например, для jamstack этих плагинов вообще может не быть.
любой плагин, написанный по стандартам, можно «адаптировать под API»
если этот плагин работает только на фронте, вытащить эту часть для headless cms так же реализуемо
статья, к сожалению, ни о чем
если бы у меня был большой опыт с WP, я бы тоже без ооочень серьезной причины не стал бы переезжать
соотносится с вот этим?
Пересядь с иглы WordPress на Static Site Generator
Что делать, если WordPress (WP) уже не вставляет, а сайт пилить надо? Кейс авторского блога
что явно намекает — что статья для людей с опытом работы с WP
повторюсь, любой довод из статьи либо не верен, либо исходит из негативного/неправильного личного опыта автора, либо в равной мере относится к WP/JAM
я использую тему Salient
это проблема конкретно этой темы, к WP никак не относится
если взять готовую верстку с кучей !important и попробовать ее использовать на статическом сайте, попутно пытаясь что-то кастомизировать, — вылезут ровно те же проблемы.
к самой технологии/движку это вообще никаким боком
Именно об этом я и говорю: вы – PHP разработчик со стажем на WordPress, я – НЕ PHP разработчик со стажем на WordPress, и не хочу тратить время на его глубокое изучение, как и вспоминать PHP.
Если вы не знаете php, это не значит, что нужно автоматом всем уйти с php движка. В идеале, еще бы и перестать агитировать всех уходить с php, но это утопично.
PHP, а я его не хочу использовать.
может это и есть основная проблема?
например, не все WP плагины нормально работают в статике.
а, например, для jamstack этих плагинов вообще может не быть.
Все ли плагины WP адаптируются под API? Нет.
любой плагин, написанный по стандартам, можно «адаптировать под API»
если этот плагин работает только на фронте, вытащить эту часть для headless cms так же реализуемо
статья, к сожалению, ни о чем
что явно намекает — что статья для людей с опытом работы с WP
Правильно, но «опыт работы» не означает, что читатель – PHP разработчик, который способен написать для WP плагин или подобное.
Я, как разработчик, специализирующийся на Full-stack TS (JS) и Golang, из-за незнания альтернатив, использовал WordPress, но уже очень давно не хотел этого делать.
JAM – это качественно новый подход, который мне заходит лучше, чем WordPress.
Вот таким же людям, как я, которые не хотят в PHP и WP я советую JAM.
А WP разработчики, возможно, подчерпнут что-то интересное и в каком-то отдельном кейсе воспользуются связкой WP + SSG, например.
Я кстати начну перенос сайта с того, что просто соединю существующий WP блог, с версткой, которая у меня есть на SSG.
если взять готовую верстку с кучей !important и попробовать ее использовать на статическом сайте, попутно пытаясь что-то кастомизировать, — вылезут ровно те же проблемы.
Да, верно, только в хороших темах для SSG на данный момент такого нет, а в одной из самых популярных WP тем, есть, вот и все.
Если вы не знаете php, это не значит, что нужно автоматом всем уйти с php движка.
Так я и не говорю уходить) Еще раз: я — НЕ PHP разработчик и для таких же как я существует JAM, о котором я не знал, а о WP знал, поэтому приходилось его использовать.
В идеале, еще бы и перестать агитировать всех уходить с php, но это утопично.
Зачем уходить с PHP? Я люблю PHP в рыночном контексте: я раньше сам писал на нем, а сейчас очень часто, когда ко мне обращаются за разработкой крупных B2B сервисов я для ядра системы набираю людей на PHP + Symfony / Laravel, а вот более тонкую обвязку можно на NodeJS / Golang.
Поэтому желаю здравия всем PHP разработчикам (и вам тоже) и буду агитировать больше людей учить Symfony, как минимум, чтобы посмотреть как круто устроить модульный фреймворк по граммотным концепциям DDD.
Symfony вообще очень неплохо устроен внутри, поэтому я постепенно портирую его концепции (DDD Light) в свою библиотеку для NodeJS + TypeScript.
может это и есть основная проблема?
А вот навязывать PHP мне не нужно, спасибо) Я не полюбил сам писать на нем тогда, не полюблю и сейчас.
а, например, для jamstack этих плагинов вообще может не быть.
Несомненно
любой плагин, написанный по стандартам, можно «адаптировать под API»
Несомненно, но для этого нужно делать доп действия, а там это из коробки и это существуенно.
статья, к сожалению, ни о чем
Жаль, что у вас не получилось узнать что-то новое, может, в следующий раз)
В опросе не хватает вариантов «пробовал и предпочитаю SSG без CMS». А пост отличный, спасибо!
Некоторые SSG умеют читать frontmatter в YAML формате. Это классно, страницам можно присваивать какие-то данные.
А есть ли какая-то HCMS или SSG, которые следят за целостностью этих данных?
У меня может быть набор из тысячи тегов и перекрестных ссылок со страницы на страницу. Хотелось бы, чтобы CMS при наборе новой страницы умела показывать существующие теги, категории или имеющиеся значения соответствующих переменных.
Есть страницы с выборками по данным других страниц и составлять таблицы. Какие SSG и HCMS умеют делать выборки по данным других страниц?
А есть ли какая-то HCMS или SSG, которые следят за целостностью этих данных?
У меня может быть набор из тысячи тегов и перекрестных ссылок со страницы на страницу. Хотелось бы, чтобы CMS при наборе новой страницы умела показывать существующие теги, категории или имеющиеся значения соответствующих переменных.
Есть страницы с выборками по данным других страниц и составлять таблицы. Какие SSG и HCMS умеют делать выборки по данным других страниц?
Мне нравятся эти быстрые сайты которые открываются моментально и пару раз я делал заходы в сторону headless, но все хорошее достаточно быстро кончается после того, как ты решаешь реально попробовать это использовать в работе, а не рекомендовать другим, многие плагины не обновляются, что то придётся писать с нуля и ради чего? Того что в вп я сделаю в два клика, а ты будешь корпеть бессонными ночами, это геморой ради геморроя , хорошо если за счёт клиентов
Sign up to leave a comment.
Пересядь с иглы WordPress на Static Site Generator и Headless CMS #нивкакиестэки