Стабильные ID полей
Поля адресуются по ID, а не по названию. Переименуйте поле в интерфейсе — все привязки шаблонов и API-интеграции продолжат работать.
Описывайте типы контента так, как инженер проектирует схему, — а не так, как навязывает конструктор страниц. У каждого поля стабильный ID, поэтому шаблоны и интеграции переживают переименование поля, а не ломаются без предупреждения.
Короткий и форматированный текст, связи, медиа, перечисления, даты, десятичные числа, JSON и типизированные компоненты дают настоящую модель контента — те же элементы, что вы использовали бы при проектировании схемы БД, но в виде структурированных полей для редакторов.
Поля адресуются по ID, а не по названию. Переименуйте поле в интерфейсе — все привязки шаблонов и API-интеграции продолжат работать.
Связывайте записи между собой и задавайте ограничения полей на уровне схемы, чтобы некорректные данные отсекались при вводе, а не всплывали дальше по цепочке.
Изменения схемы проходят пробный прогон с оценкой последствий и применяются только вперёд — развитие типа контента никогда не сбрасывает уже созданные записи.
Создайте переиспользуемые вложенные компоненты один раз, а редакторы будут собирать гибкие тела страниц из разрешённого набора блоков — без скопированных групп полей и без тикетов разработчику ради перестановки блоков.
Опишите компонент — адрес, тарифный уровень, пункт FAQ — один раз и используйте его во всех типах контента, где он нужен.
Дайте редакторам подобранный набор блоков для сборки тела страницы, не открывая вёрстку для произвольного HTML.
Каждое поле может хранить значения для разных локалей с понятной исходной записью в локали по умолчанию, так что перевод остаётся структурированным, а не дублированным.
Опишите поля, добавьте компонент и посмотрите на сгенерированную страницу, привязанную к реальным данным.