Konso CMS 2.0: управление контентом на основе схем

Что такое Konso CMS 2.0?

Konso CMS 2.0 — это полностью schema-driven система управления контентом, встроенная в платформу Konso. В отличие от фиксированных CMS, где структура данных задана заранее, в CMS 2.0 вы сами описываете, что такое "контент" для вашего проекта: какие поля нужны, какие типы данных, какие правила валидации. Это headless-подход: контент хранится в базе данных, управляется через API, а рендеринг остаётся на стороне вашего фронтенда. Konso предоставляет Delivery API для получения опубликованных записей.

Типы контента и динамические поля

Основная единица CMS 2.0 — тип контента (content type). Это схема, которая описывает набор полей и правила их заполнения. Например, тип "Статья" может содержать заголовок, текст, дату публикации, изображение-обложку и теги.

Поддерживаемые типы полей

• check_circleshorttext — однострочный текст
• check_circlelongText — многострочный текст
• check_circlerichText — форматированный текст с разметкой
• check_circlenumber — числовое значение
• check_circleboolean — флаг (да/нет)
• check_circledate — дата
• check_circledatetime — дата и время
• check_circleslug — URL-совместимый идентификатор (с автогенерацией из другого поля)
• check_circleselect — выбор из заданного списка значений
• check_circlemedia — ссылка на медиа-актив
• check_circlereference — связь с другими записями (например, пост → категории)
• check_circlejson object — произвольный JSON

Валидация на уровне схемы

Каждое поле можно сконфигурировать с правилами валидации. Они применяются на сервере при создании и обновлении записей — клиент не может обойти их.

Доступные правила валидации

Publishing workflow

Каждая запись контента проходит через три статуса. Переход между статусами — это отдельные API-действия, а не просто обновление поля. Это позволяет точно отслеживать историю публикаций и хранить временны́е метки.

Медиа-активы

Медиа хранится отдельно от записей контента в таблице cms_media_assets. Каждый актив имеет свой prefixed ID с префиксом med_. В полях типа media хранится только ID актива, а не сам файл — это позволяет переиспользовать одно изображение в нескольких записях без дублирования. Загрузка файлов происходит через multipart upload. Поддерживаются поля: название, MIME-тип, размер, storage_key и публичный URL.

Prefixed ID: читаемые идентификаторы

Все сущности CMS 2.0 используют префиксные ID вместо обычных UUID. Формат: _<8 случайных символов>.

Префиксы сущностей

Delivery API

Delivery API — это отдельный публичный эндпоинт для получения опубликованного контента. Он возвращает только записи со статусом published, что позволяет безопасно использовать его на фронтенде без риска утечки черновиков. Основные возможности: - Получение списка записей с фильтрацией по типу контента, статусу и JSONB-полям - Получение записи по ID или slug - Пагинация и сортировка Shared DAL (Data Access Layer) гарантирует, что App API и Delivery API работают с одними и теми же хранимыми процедурами PostgreSQL — логика фильтрации не дублируется.

Архитектурные решения: JSONB и PostgreSQL

Поля записей хранятся в колонке fields типа JSONB. Это даёт гибкость: разные типы контента имеют разные наборы полей, но все записи находятся в одной таблице cms_content_entries. GIN-индекс на JSONB обеспечивает быструю фильтрацию по значениям полей без полного скана таблицы. Схема типа контента версионируется (schema_version). При каждом обновлении схемы версия инкрементируется, и каждая запись хранит версию схемы, по которой она была создана — это основа для будущей миграции данных.

Что включено в MVP

• check_circleУправление типами контента с динамическими полями
• check_circleСоздание и редактирование записей контента
• check_circleФильтрация по статусу, типу контента и JSONB-полям
• check_circlePublishing workflow (draft / published / archived)
• check_circleМедиа-активы с загрузкой файлов
• check_circleDelivery API для получения опубликованного контента
• check_circleВалидация схемы и записей на сервере
• check_circleShared DAL с хранимыми процедурами PostgreSQL