Глоссарий терминов

Статус: зафиксировано (брейншторм закрыт). Слова «модуль / блок / виджет / компонент / тема» в Битриксе, WordPress и Laravel значат разное — путаница здесь источник дорогих архитектурных ошибок. Этот словарь фиксирует, что каждое означает именно в нашей CMS.

Карта слоёв

Ядро (cms/core)          — то, что нужно любому сайту
  └── Модуль              — то, что нужно некоторым сайтам (composer-пакет)
        └── Блок          — типизированная единица контента страницы
        └── Виджет        — переиспользуемый элемент в областях (сайдбар, футер)
        └── Компонент     — низкоуровневый строительный кирпич (Blade/React)
  └── Тема                — то, что у каждого сайта своё (вид, токены)

Термины

Ядро (Core)

Пакет cms/core — универсальное ядро: богатые базовые механизмы (движок полей, события/хуки, очереди, кеш, API-слой) + редакторы-инструменты (сущности, типы данных, файлы, пользователи) + контент-движок (страницы и блоки, BlockRegistry, произвольные типы, меню, виджеты), настройки, медиатека, SEO-база, формы/заявки, права, админ-shell (Filament). Ставится как composer-пакет в vendor/. Универсальное, но фичи поверх — через включаемые модули (см. каталог подсистем).

Битрикс-аналогия: главный модуль main + ядро D7.

Модуль (Module)

Composer-пакет, добавляющий функциональность, нужную некоторым сайтам: каталог, мультигород, блог, калькулятор, платежи, AI-контент. Привозит свои миграции, роуты, Filament-плагин, права, блоки, события. Устанавливается на конкретный сайт по мере необходимости. См. Реестр модулей и контракт модуля.

Битрикс-аналогия: модуль (sale, catalog, iblock) — но у нас через composer, а не проприетарный маркетплейс.

Блок (Block)

Типизированная единица контента страницы со строгой схемой полей. Из блоков контент-менеджер собирает страницу drag&drop-ом. Каждый блок = описание в BlockRegistry (renderer + Filament-схема формы + demo-props + версия схемы + флаг interactive). Props хранятся в JSONB. Примеры: hero, features, FAQ, галерея, CTA, каталог-грид.

Битрикс-аналогия: ближе всего к «инфоблоку в составе страницы» + элемент лендинг-блока из модуля landing. WordPress-аналогия: блок Gutenberg (включая версии схем — _v).

Виджет (Widget)

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

Битрикс-аналогия: включаемые области. WordPress-аналогия: виджеты (то же слово).

Решено (Q4): виджет — отдельная сущность, не частный случай блока. Разные жизненные циклы и места хранения: блок привязан к записи страницы, виджет — к области и появляется на многих страницах. Ядро получает WidgetRegistry (аналог BlockRegistry для областей).

Компонент (Component)

Низкоуровневый строительный кирпич интерфейса — Blade-компонент (публичный сайт) или React-компонент (кабинет/остров). Блоки и виджеты состоят из компонентов. Компонент не имеет собственной схемы данных в админке — это чистый элемент разметки (кнопка, карточка, breadcrumbs).

Битрикс-аналогия: компонент Битрикс (CBitrixComponent) — но у Битрикса компонент несёт и данные, и шаблон; у нас данные несёт блок, компонент — только представление. Это важное расхождение: не путать наш «компонент» с битриксовым.

Тема (Theme)

Пакет визуального слоя: Blade-переопределения блоков + theme.json (дизайн-токены: цвета, шрифты, радиусы) + Vite-сборка (+ React-острова). Определяет, как выглядят блоки, не меняя их данные. Темы переключаются; контент остаётся. Каскад разрешения шаблона: проект → активная тема → родительская тема → fallback ядра.

Битрикс-аналогия: шаблон сайта (/local/templates/). WordPress-аналогия: тема (child themes = родительские темы у нас).

Страница (Page)

Запись в БД, собранная из упорядоченного списка блоков. Имеет slug, SEO-поля, привязку к меню. Контент-менеджер редактирует страницу через drag&drop блоков в Filament. Блоки хранятся не в самой странице, а в ревизиях (cms_page_revisions); страница указывает на опубликованную ревизию (Q7, модель данных).

Настройка (Setting)

Значение из БД, доступное через setting('group.key') с fallback на config. Редактируется на странице настроек в Filament. Примеры: телефон, реквизиты, соцсети. Секреты (API-ключи, токены платёжек) в настройках не хранятся — только .env → config() (три оси).

Матрица «где что живёт»

Сущность	Где данные	Где вид	Кто редактирует	Схема
Блок	JSONB в ревизии страницы (Q7)	Blade-партиал темы	контент-менеджер (drag&drop)	строгая (BlockRegistry)
Виджет	своя таблица/настройки	Blade-партиал	контент-менеджер	строгая
Компонент	нет (получает props)	Blade/React	разработчик	нет
Тема	theme.json	сама тема	разработчик студии	токены
Страница	cms_pages + ревизии (published_revision_id)	сборка блоков	контент-менеджер	—
Настройка	таблица cms_settings	—	контент-менеджер	key-value

Чем наши термины отличаются от Битрикс

Термин	В Битрикс	В нашей CMS
Компонент	несёт данные И шаблон (CBitrixComponent)	только представление; данные — в блоке
Модуль	проприетарный, через маркетплейс 1С	composer-пакет через приватный Satis
/local	папка кастомизации	app/Local/ в проекте (см. расширяемость)
init.php	файл-свалка обработчиков	папка авто-подхватываемых классов-хуков
Инфоблок	универсальная EAV-сущность	два разных понятия — см. ниже

Блок vs Тип контента (аналоги «инфоблока»)

У Битрикс «инфоблок» — одно понятие для всего. У нас — два, чтобы не путать:

• Блок — единица страницы со строгой схемой (hero, FAQ, галерея). Собирается drag&drop-ом. Props в JSONB.
• Тип контента — самостоятельная сущность с произвольными полями («вакансии», «объекты недвижимости»), со своим списком и детальной страницей. Клиент заводит без разработчика.

Решено (Q5): произвольные типы контента — в ядре с 1.0, но реализованы через JSONB-колонку + GIN-индексы, а НЕ классический EAV. Это даёт гибкость инфоблоков без деградации производительности и SEO, которой страдает EAV. Поля с бизнес-смыслом (фильтрация, URL) выносятся в generated-колонки поверх JSONB.