Craft CMS и Statamic: выбор CMS для заказного контентного сайта

Craft CMS и Statamic занимают близкую нишу: обе системы предназначены для разработки заказных сайтов, в которых структуру контента, редакторский интерфейс и фронтенд проектируют под конкретную задачу. Они не навязывают готовую тему и не ограничивают разработчика набором типовых страниц, поэтому подходят для корпоративных сайтов, медиа, образовательных проектов, баз знаний, каталогов и контентных сервисов.

При внешнем сходстве архитектура систем различается. Craft CMS — самостоятельное PHP-приложение на Yii, использующее Twig и реляционную базу данных. Statamic глубоко интегрирован с Laravel, предлагает Antlers и Blade, а контент по умолчанию может хранить в файлах. При необходимости Statamic позволяет перенести записи и другие поддерживаемые сущности в базу данных.

Начинать выбор стоит не с количества возможностей в сравнительной таблице, а с архитектуры проекта: объёма и связанности данных, процесса публикации, числа редакторов, требований к локализации, способа развёртывания и возможностей хостинга.

Краткое сравнение Craft CMS и Statamic

• Архитектурная основа: Craft CMS — самостоятельное PHP-приложение на Yii; Statamic — CMS, интегрированная с Laravel.
• Хранение контента: Craft использует MySQL, MariaDB или PostgreSQL; Statamic по умолчанию ориентирован на файлы, но поддерживает хранение через Eloquent Driver.
• Шаблонизация: Craft использует Twig; Statamic предлагает собственный язык Antlers и Laravel Blade.
• Модель контента: Craft делает акцент на универсальных элементах, типах записей, разделах и отношениях; Statamic — на коллекциях, таксономиях, глобальных наборах и Blueprints.
• Мультиязычность: обе CMS поддерживают несколько сайтов, языков, доменов и региональных вариантов в рамках связанного проекта.
• Работа с Git: Craft хранит схему проекта в YAML, а опубликованный контент — в базе данных; Statamic может хранить в репозитории и конфигурацию, и сам контент.
• Типичная команда: Craft удобен для проектов со сложными отношениями и формализованной редакционной моделью; Statamic особенно привлекателен для Laravel-команд и файловых Git-ориентированных процессов.

Это не означает, что Craft нельзя использовать для небольшого сайта, а Statamic — для крупного. Речь идёт о естественных сценариях, в которых архитектурные преимущества каждой системы проявляются с меньшим количеством дополнительных решений.

Моделирование контента в Craft CMS

Основная контентная сущность Craft — entry, то есть запись. Типы записей определяют состав и расположение полей, а разделы организуют записи и задают их поведение: доступность URL, правила формирования адресов, шаблоны, способы предпросмотра и доступность на разных сайтах.

Раздел может представлять одиночную страницу, плоский поток материалов или иерархическую структуру. Это позволяет отдельно моделировать главную страницу, новости, услуги, документацию, подразделения компании и другие сущности, не сводя их к универсальному типу «страница».

Отношения — одна из сильных сторон Craft. Запись можно связать с другими записями, категориями, тегами, ресурсами и пользователями. Например, у кейса могут быть связанные услуги, отрасли, сотрудники, документы и похожие проекты. Разработчик получает не строковые идентификаторы, а запросы к полноценным элементам CMS.

Для модульной сборки страниц используется Matrix. В Craft 5 элементы внутри Matrix являются вложенными записями. Типы записей можно применять как самостоятельные сущности раздела или как блоки внутри другого материала. Такой подход полезен, когда одни и те же смысловые компоненты, например цитата, галерея или промоблок, должны иметь последовательную структуру в разных частях проекта.

Гибкость требует дисциплины. Если создавать отдельное поле для каждого похожего случая или строить чрезмерно глубокие вложенные структуры, панель управления станет сложной для редакторов, а шаблоны — трудными для сопровождения. До начала разработки полезно определить:

• какие объекты должны существовать независимо и переиспользоваться;
• какие данные принадлежат только одной странице;
• где необходима связь, а где достаточно вложенного блока;
• какие поля переводятся, а какие одинаковы для всех локализаций;
• какие изменения редактор может выполнять без участия разработчика.

Craft хорошо подходит для модели, близкой к предметной области заказчика. Вместо общего раздела страниц можно создать отдельные типы «Услуга», «Эксперт», «Проект», «Документ» и «Мероприятие», а затем связать их между собой.

Моделирование контента в Statamic

В Statamic структура публикации строится вокруг коллекций, записей, таксономий, глобальных данных, навигаций и Blueprints. Blueprint задаёт поля, их типы, группировку и условия отображения в редакторской форме. В одной коллекции может быть несколько Blueprints, если материалы имеют общую роль, но отличаются набором данных.

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

Statamic также поддерживает отношения между материалами, таксономиями и ресурсами. Для гибких страниц доступны поля, позволяющие редактору собирать содержимое из заранее определённых наборов. Практический результат похож на модульные страницы Craft: студия проектирует библиотеку компонентов, а редактор комбинирует только разрешённые варианты.

Главное концептуальное отличие проявляется в хранении. При файловой модели запись представляет собой файл с метаданными и содержимым, а структура CMS находится рядом с кодом проекта. Такой формат прозрачен для разработчика: изменения можно просматривать в Git, переносить между ветками и анализировать как обычный текст.

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

Какая модель удобнее для сложного контентного сайта

Craft чаще оказывается естественным выбором, когда в проекте много взаимосвязанных сущностей и запросов по их атрибутам. Реляционная база является обязательной частью архитектуры, а единая система элементов даёт последовательный способ работы с записями, категориями, файлами и пользователями.

Statamic особенно удобен, когда структура контента относительно понятна, файловое хранение соответствует объёму проекта, а команда хочет видеть изменения публикаций в репозитории. При росте объёма или изменении требований можно подключить Eloquent Driver и перенести выбранные репозитории в базу данных, оставив конфигурацию в файлах.

Не следует выбирать Statamic только из предположения, что файлы всегда быстрее базы данных. Итоговая производительность зависит от числа записей, связей, фильтров, кэширования, шаблонов, файловой системы и серверной конфигурации. Аналогично наличие базы данных у Craft не делает любой сложный запрос автоматически эффективным: разработчик должен контролировать выборки, предварительную загрузку связанных элементов и кэширование.

Мультиязычность и несколько сайтов

Обе CMS используют понятие нескольких сайтов для языковых, региональных или брендовых вариантов связанного проекта. Сайт может работать на отдельном домене, поддомене или в каталоге основного домена. При этом multi-site не следует путать с мультитенантной платформой, где независимые клиенты управляют изолированными проектами.

Локализация в Craft CMS

Одна установка Craft может обслуживать несколько связанных сайтов. Для разделов задаются правила распространения записей, а для полей — способы перевода значений. Часть данных можно сделать общей, часть — переводимой для каждого сайта, а часть — различающейся в пределах группы сайтов.

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

Гибкость Craft полезна для сложных региональных правил, но повышает цену ошибки при проектировании. Если поле сначала сделать общим, наполнить данными, а затем изменить его способ перевода, команде придётся внимательно проверить значения во всех локализациях. Политику распространения и перевода лучше утвердить до массового ввода материалов.

Локализация в Statamic

Multi-site в Statamic предназначен для вариантов одного сайта, языков, регионов или связанных брендов. Локализованная запись может наследовать данные от исходной, а отдельные поля — переопределяться для конкретной версии. Коллекции настраиваются с учётом сайтов, в которых они доступны.

Файловое хранение делает структуру локализаций видимой в проекте, что удобно разработчикам, но увеличивает количество файлов и потенциальных конфликтов при параллельном редактировании через Git. Для большой распределённой редакции необходимо заранее определить, как будут выполняться публикация, блокировки, разрешение конфликтов и развёртывание изменений.

Ни Craft multi-site, ни обычный Statamic multi-site не следует использовать как универсальный механизм для размещения множества не связанных друг с другом клиентских сайтов. Если у проектов разные владельцы, права доступа, жизненные циклы и обновления, безопаснее рассматривать отдельные установки или специализированную платформенную модель.

Шаблоны и разработка фронтенда

Twig в Craft CMS

Craft использует Twig для серверного рендеринга. В шаблонах доступны запросы к элементам, фильтры, макросы, включения и наследование. Разработчик может получать записи по разделу и типу, загружать связанные элементы и выводить вложенные записи Matrix.

Twig помогает отделить представление от PHP-кода и хорошо подходит для сайтов, где основная логика фронтенда связана с выборкой и отображением контента. Более сложное поведение можно перенести в модуль или плагин на Yii, не превращая шаблон в слой бизнес-логики.

Для команды, уже работающей с Twig в других PHP-проектах, входной порог обычно невысок. Но разработчику всё равно потребуется изучить модель элементов Craft, построитель запросов, правила предварительной загрузки связей, маршрутизацию и особенности предпросмотра.

Antlers и Blade в Statamic

Statamic предлагает два основных пути. Antlers тесно интегрирован с CMS и позволяет получать коллекции, фильтровать данные, работать с переменными, модификаторами, частичными шаблонами и встроенными тегами. Он удобен для контентных сайтов, где требуется быстро собирать представления без большого количества контроллеров.

Blade подходит Laravel-командам и проектам, в которых CMS является частью более широкого приложения. Разработчик может применять привычные компоненты, директивы, маршруты, контроллеры и сервисы Laravel. Antlers и Blade допускается сочетать, однако смешанный подход лучше регламентировать, чтобы разные разделы сайта не использовали случайные несовместимые соглашения.

Если студия специализируется на Laravel, Statamic даёт заметное организационное преимущество: существующие библиотеки, подходы к тестированию и опыт команды переносятся в CMS-проект. Если основной стек команды строится вокруг Twig или уже накоплены модули Craft, переход на Statamic только ради файлового контента может не окупить обучение и миграцию.

Хранение данных и процесс развёртывания

Craft: контент в базе данных, схема в Project Config

Craft хранит содержимое в реляционной базе данных. Настройки модели — поля, разделы, типы записей, сайты и другие системные параметры — отражаются в YAML-файлах Project Config. Их можно хранить в Git и применять на тестовом или рабочем окружении во время развёртывания.

Такое разделение защищает редакционные данные от перезаписи при выпуске новой версии сайта. Разработчик меняет модель на локальном окружении, фиксирует Project Config вместе с шаблонами и зависимостями, а на сервере применяет миграции и изменения конфигурации. База production при этом остаётся источником опубликованного контента.

Нельзя считать Project Config резервной копией сайта: в нём нет самих публикаций. Для восстановления потребуются отдельные резервные копии базы данных, пользовательских файлов, конфигурации и секретов окружения. Для планирования этой части инфраструктуры пригодится материал о резервном копировании сайта и проверке восстановления.

Statamic: файлы, база данных или смешанная схема

По умолчанию Statamic хранит контент в плоских файлах. Это позволяет версионировать публикации, просматривать diff и переносить изменения вместе с кодом. Подход особенно удобен, когда материалы готовят разработчики или небольшая команда, а выпуск сайта привязан к Git-процессу.

У файловой модели есть организационная цена. Если редактор меняет production через панель, а разработчик одновременно развёртывает старую ветку, необходимо исключить потерю изменений. Для автоматической фиксации действий панели в Git требуются корректно настроенные лицензия, репозиторий, права, стратегия ветвления и правила разрешения конфликтов.

Для проектов с большим числом материалов, активной редакцией или сложными запросами Statamic позволяет хранить записи и другие поддерживаемые репозитории через Eloquent Driver. Возможен смешанный вариант: схема и служебная конфигурация остаются файлами, а регулярно изменяемый контент переносится в базу данных.

Фраза «flat-file CMS» не гарантирует, что проекту вообще не понадобится СУБД. Конкретное приложение, дополнения, пользователи, очереди или другие компоненты Laravel могут использовать базу данных. Требования следует определять по итоговой конфигурации, а не только по базовой установке CMS.

Лицензирование и стоимость владения

У Craft есть бесплатная редакция Solo с одной учётной записью, а коммерческие редакции Team и Pro отличаются лимитом пользователей и набором возможностей. У Statamic доступна бесплатная редакция Core с ограничениями редакционной части и коммерческая редакция Pro, включающая многопользовательскую работу, роли, ревизии, multi-site и Git-интеграцию панели управления.

Лицензионные условия, цены и состав редакций могут меняться, поэтому перед составлением коммерческого предложения их необходимо проверить у разработчиков CMS. Помимо лицензии в бюджет следует включить:

• платные плагины и дополнения;
• разработку и поддержку собственных модулей;
• обновления PHP, CMS и зависимостей Composer;
• тестовый контур и автоматизацию развёртывания;
• резервное копирование базы данных и файлов;
• мониторинг очередей, ошибок и свободного места;
• обучение редакторов и документирование модели контента.

Для небольшого проекта разница в цене лицензии обычно менее значима, чем стоимость разработки и последующей поддержки. CMS, знакомая команде и соответствующая архитектуре сайта, способна сэкономить больше, чем формально более дешёвая лицензия.

Требования к PHP-хостингу

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

Требования Craft CMS 5

Для Craft CMS 5 требуется PHP 8.2 или новее, Composer 2, не менее 256 МБ памяти PHP и поддерживаемая реляционная база данных: MySQL 8.0.17 или новее с InnoDB, MariaDB 10.4.6 или новее либо PostgreSQL 13 или новее. Для рабочего проекта документация рекомендует ориентироваться как минимум на 512 МБ памяти. Также необходимы BCMath, cURL, GD, Intl, mbstring, OpenSSL, PDO, Zip, DOM и другие стандартные PHP-модули.

На виртуальном хостинге важно уточнить, не отключены ли функции, необходимые Composer, установке обновлений, отправке почты и обработке очередей. Если провайдер запрещает запуск CLI-команд, не предоставляет cron или жёстко ограничивает фоновые процессы, часть операций придётся выполнять вручную либо переносить проект на VPS.

Требования Statamic 6

Statamic 6 требует PHP 8.3 или новее, Composer и расширения, необходимые Laravel и самой CMS: BCMath, Ctype, Exif, JSON, Mbstring, OpenSSL, PDO, Tokenizer и XML. Для обработки изображений нужен GD или ImageMagick.

Statamic может работать на совместимом виртуальном хостинге, если тот позволяет направить домен на публичный каталог проекта, выполнять Composer- и CLI-команды, задавать переменные окружения и обеспечивать запись в нужные директории. Для файлового контента особенно важны корректные права и надёжное резервное копирование. Если используется Git-автоматизация, серверу потребуются безопасно настроенный доступ к репозиторию и возможность выполнять соответствующие процессы.

VPS даёт больше контроля над PHP, очередями, cron, кэшем и процессом развёртывания, но требует администрирования. Виртуальный хостинг снимает часть этой нагрузки, однако команда зависит от доступных версий и ограничений провайдера. Нельзя рассчитывать, что возможность выбрать нужную версию PHP автоматически означает полную совместимость с CMS.

Облачный VDS-сервер

Виртуальные серверы с быстрым запуском и гибкой конфигурацией от 390₽ / мес

Доступные локации

Россия Нидерланды

Смотреть тарифы

Права редакторов и удобство панели

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

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

В Statamic многопользовательские роли, история контента, черновики и связанные командные функции относятся к Pro. Преимуществом может стать сочетание панели и Git-процесса: техническая команда получает историю файлов, а редакторы продолжают работать через привычные формы. Но Git не заменяет бизнес-процесс согласования и не должен быть единственным механизмом резервного копирования.

Когда лучше выбрать Craft CMS

• В проекте много типов сущностей и связей между ними.
• Контент регулярно фильтруется по полям, категориям, авторам и отношениям.
• Нужна сложная мультиязычность с разными правилами перевода отдельных полей.
• Редакция работает непосредственно на production, а схема доставляется отдельно через Git.
• Команда предпочитает Twig и готова работать с Yii и моделью элементов Craft.
• Реляционная база данных изначально является обязательной частью инфраструктуры.
• Необходима детально настроенная панель для большой редакционной команды.

Типичный сценарий — многоязычный корпоративный портал, где услуги связаны с отраслями, кейсами, сотрудниками, офисами и документами, а разные подразделения имеют собственные права публикации.

Когда лучше выбрать Statamic

• Команда уже разрабатывает на Laravel и хочет использовать знакомую экосистему.
• Контент удобно хранить и версионировать вместе с проектом.
• Сайт выпускается через контролируемый Git-процесс.
• Нужен выбор между Antlers и полноценным Blade.
• Структура сайта достаточно ясна, а объём файлового контента соответствует возможностям инфраструктуры.
• Важно иметь возможность позднее перенести выбранные данные в базу данных.
• CMS встраивается в более крупное Laravel-приложение с собственной бизнес-логикой.

Характерный пример — сайт продукта или документационный ресурс, который поддерживает Laravel-команда, а изменения контента должны проходить через ветки, проверку и предсказуемое развёртывание.

Вопросы, которые стоит задать до выбора

1. Где должен находиться источник истины? В production-базе данных, как обычно происходит с Craft, или в файлах репозитория, что возможно со Statamic?
2. Кто меняет структуру контента? Только разработчики или администраторы рабочего сайта тоже должны создавать поля и типы материалов?
3. Сколько будет связей? Если большая часть страниц собирается из взаимосвязанных сущностей и сложных выборок, реляционная модель Craft может оказаться понятнее.
4. Как устроена локализация? Нужен прямой перевод страниц или региональные версии с частично общими данными и разными правилами публикации?
5. Как редакторы работают параллельно? Файловая модель требует особенно внимательно оценить конфликты и доставку изменений.
6. Какой стек уже знает команда? Опыт Laravel и Blade усиливает аргументы за Statamic, а опыт Twig и Craft сокращает риски выбора Craft.
7. Что умеет хостинг? Следует проверить PHP, расширения, Composer, CLI, cron, права на каталоги, базу данных, память и фоновые процессы.
8. Какие дополнения обязательны? Нужно заранее проверить их совместимость, лицензии, частоту обновлений и качество поддержки.

Итоговый выбор

Craft CMS и Statamic решают одну задачу разными способами. Craft предлагает последовательную реляционную модель контента, развитые связи, гибкую локализацию и отделение схемы проекта от редакционных данных. Он особенно убедителен для насыщенных сущностями сайтов и формализованных редакционных процессов.

Statamic сочетает CMS с экосистемой Laravel, даёт выбор между Antlers и Blade и позволяет начать с файлового хранения, сохранив возможность перехода к базе данных. Он хорошо подходит командам, которые ценят прозрачность файлов, Git-ориентированную доставку и повторное использование Laravel-компонентов.

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