Как выбрать: дерево решений для вашего проекта

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

Метод вместо вкуса

Мы разобрали пять путей: WordPress, конструктор, Битрикс, генератор статики и headless CMS. Остался вопрос, как выбрать. Ответ не про вкус и не про моду. Выбор следует из пяти вопросов о вашем проекте, и вы уже знаете, как каждый из них действует:

1. Кто правит содержание? Владелец без технических знаний, редактор в команде или разработчик? (Урок 1.)
2. Как часто? Каждый день, раз в неделю, раз в месяц, раз в полгода? От этого зависит, нужна ли удобная админка. (Урок 1.)
3. Что нужно кроме страниц? Форма заявки, магазин, личный кабинет? Каждое из них либо входит в платформу, либо подключается сервисом, либо означает своё приложение. (Уроки 4 и 7.)
4. Какой бюджет? Деньги на старте, подписка каждый год, время на обслуживание. (Уроки 3 и 4.)
5. Сколько языков? Один язык проще всего. Для двух нужны поля на каждый язык или переводы записей. (Урок 1.)

Нажмите на готовые проекты в схеме и меняйте ответы: вы увидите, как решение смещается. Это не истина, а способ увидеть логику.

Сводка по путям

Когда не стоит делать свою CMS

Самый соблазнительный вариант для разработчика: «я напишу свою, мне же проще». Это почти всегда ошибка, и вот почему.

CMS это в основном скучная работа. Форма правки это небольшая часть. Остальное: пользователи и роли, пароли и восстановление доступа, черновики и версии, медиатека с обрезкой и сжатием картинок, поля для SEO, многоязычие, предпросмотр, резервные копии, защита от взломов, обновления зависимостей, журнал изменений. Каждое из этого есть в готовых системах и прошло через тысячи проектов, а у вас это будет не менее года работы и бесконечная поддержка.

«Домашняя» CMS становится ловушкой. В 2000-х многие студии писали свои системы для клиентов. Пока автор в студии, всё хорошо. Когда он уходит, система остаётся без хозяина, её никто не обновляет, в ней находят дыры, а клиенту некуда переехать. Заказчик попадает в заложники.

Есть порядок, в котором стоит искать решение. Сначала настроить то, что есть. Потом взять готовое: плагин, сервис, блок. Потом собрать из готовых частей (например, генератор плюс headless CMS). И писать своё только после того, как вы измерили, что иначе не выйдет. Этот порядок годится не только для CMS: свою аутентификацию, оплату, поиск и отправку почты тоже не пишут (об аутентификации в части 6 сказано то же самое).

Исключения есть: когда CMS и есть ваш продукт, когда у проекта уникальная модель данных и команда, которая её сопровождает, и когда вы учитесь. А самая дешёвая «своя CMS» это Markdown-файлы в Git: тексты лежат файлами, правки это коммиты. Её не нужно писать, она уже сделана.

Не запереть себя

Хороший выбор можно передумать. Для этого три привычки. Держите содержание в переносимом виде: Markdown, JSON, выгрузка SQL, а не только в закрытом редакторе платформы. Не меняйте адреса страниц без нужды: адреса это память поисковиков и ссылок. И проверьте выход заранее: раз в год выгрузите сайт и проверьте, что можно было бы унести.

Практика

Вы в эпохе 2022 года, но смотрите на всё сразу. Соберите в карточку решения всё, что вы узнали в этой части: кто правит и как часто, что обслуживает главное действие, как хранятся языки, бюджет, выбранный стек и два отвергнутых с разными причинами. Закончите условием, при котором вы пересмотрите решение.

Что было не так

Выбор «по знакомству» и «по студии» губил проекты, потому что изменения платформы никто не предсказывал. Эти три привычки (причины, отвергнутые варианты, условие пересмотра) превращают выбор из ставки в решение, которое можно проверить и поправить.