Введение
Самый мощный тип свойств EPiServer Область содержимого поддерживает ряд вариантов использования. Редакторы могут хранить там все типы контента: страницы, блоки, медиа, видео и т. д.
ContentArea хранит не только ссылки на эти элементы контента, но и их имена, типы и информацию о персонализации.
На этапе рендеринга модуль рендеринга свойств циклически перебирает элементы ContentAreaItem, применяет правила персонализации на основе текущего идентификатора, а затем пытается найти представление для каждого элемента.
Он действительно достаточно гибкий, поскольку позволяет редакторам создавать любые виды макетов, используя только одно свойство на странице или комбинируя несколько свойств ContentArea.
Редактор может либо выбрать существующий экземпляр IContent, либо принять решение о создании нового блока.
Блоки, созданные через ContentArea, помещались в папки «Для этой страницы/блока» и были доступны через панель «Активы»:
Из-за того, что каждый блок представляет собой отдельный IContent, невозможно легко просмотреть изменения, просмотреть рецензенты и, наконец, опубликовать все элементы как один раз.
Было несколько попыток решить эту проблему, одна из них — пакет Block Enhancements Labs:
https://nuget.optimizely.com/package/?id=EPiServer.Labs.BlockEnhancements
https://world.optimizely.com/blogs/grzegorz-wiechec/dates/2019/7/episerver-labs—block-enhancements/
https://world.optimizely.com/blogs/bartosz-sekula/dates/2021/9/block-enhancements-update/
Это немного громоздко, что после создания страницы с несколькими блоками внутри редактор должен не забывать всегда проверять каждую зависимость страницы, чтобы убедиться, что она находится в правильном состоянии. Что каждый зависимый блок также должен быть отправлен на проверку или добавлен в проект, даже если он используется только один раз на этой единственной странице.
Встроенные блоки внутри ContentArea
В EPiServer.CMS 12.21.0 мы выпускаем большое улучшение ContentArea. Теперь можно хранить BlockData внутри ContentAreaItem как обычный объект.
Больше не требуется никаких ухищрений для синхронизации родительской страницы с зависимостями, чтобы опубликовать их все сразу. Редактору просто нужно иметь дело с одним фрагментом контента (страницей, многоканальным контентом и т. д.), и теперь ему разрешено встраивать блочные данные и делать их частью этого родительского контента.
Ничего не меняется в отношении определения свойства в коде, ContentArea по-прежнему определяется так же:
public virtual ContentArea ContentItems { get; set; }По-прежнему можно ограничить доступные типы контента с помощью Разрешенные типы атрибут
[AllowedTypes(typeof(TeaserBlock), typeof(EditorialBlock), typeof(ContactBlock)]
public virtual ContentArea ContentItems { get; set; }Пользовательский интерфейс также остается прежним:
Однако после нажатия Создать новый блок мы больше не собираемся создавать новый экземпляр блока, который будет виден в Для этой страницы папка.
Вместо этого мы создадим набор свойств и встроим этот набор свойств в ContentAreaItem instance и сохраните его внутри родительского содержимого.
После выбора типа и заполнения реквизитов:
Мы можем сразу увидеть результат:
После изменения этого ContentAreaItem нам больше не нужно публиковать блок, вместо этого мы получим новую версию родительской страницы.
Это имеет несколько последствий:
- Редактору больше не нужно переключать контекст, чтобы редактировать эти встроенные блоки.
- Встроенные блоки внутри ContentArea не имеют собственного жизненного цикла публикации, они являются частью страницы.
- Эти элементы также не имеют рабочего процесса утверждения сами по себе. Это родительский контент, который должен быть рассмотрен и одобрен.
- Эти элементы не будут включены в проекты, только их родительский контент в целом.
Допустим, мы публикуем страницу сейчас, но через некоторое время редактор решает изменить тест на нашем КнопкаБлок
Для этого мы можем просто запустить Редактировать команду или дважды щелкните элемент области содержимого.
Измените свойства:
А после сохранения диалога мы можем сразу увидеть изменения на странице:
Как видите, была создана новая версия страницы. Мы можем легко просмотреть, как страница будет выглядеть после изменений. Мы также можем использовать режим сравнения:
Рендеринг
Для рендеринга встроенных блоков не требуется никаких специальных атрибутов или методов. Они будут вести себя точно так же, как обычные блоки.
Если у вас есть шаблон отображения, определенный для определенного типа блока, тогда среда выполнения подберет его и использует.
Миграция
Если у вас есть существующие локальные или общие блоки, которые вы хотите встроить в свойства ContentArea, у вас есть два варианта:
- Мы добавили служебную команду, которая преобразует ContentAreaItem во встроенную версию. Оригинальный IContent не удаляется, вам нужно будет очистить вручную
- Существует плагин режима администратора, доступный в Лаборатория улучшений блоков 1.2.0
Миграцию можно выполнить в 3 этапа:
- Преобразование общих блоков, используемых только один раз, в соответствующую папку «Для этой страницы».
- Сделать блоки из «Для этой страницы» встроенными в свойства ContentArea
- Удалите пустые папки из панели ресурсов.
Все этапы можно запускать одновременно или по отдельности. Тебе решать.
Изменения в команде ContentArea «Создать новый блок»
До CMS 12.21.0 нажатие кнопки ссылки «Создать новый блок»:
Создаст новый блок в папке «Для этой страницы». После обновления до CMS 12.21.0 это уже не так, и невозможно вернуть старое поведение.
Это сознательное решение с нашей стороны. Мы хотим упростить публикацию и предварительный просмотр контента и не требовать от пользователей публиковать каждый блок отдельно.
Изменения в общем контенте
Каждый общий элемент (по сути, каждый экземпляр контента, который имеет идентификатор и на который может ссылаться что-то еще) будет четко помечен меткой «ОБЩИЙ». Как в представлении форм, так и в режиме редактирования на странице.
Кроме того, при редактировании общего блока через «Быстрое редактирование» теперь отображается предупреждение, если редактируемый элемент используется более одного раза:
Свойство ContentAreaItem
Еще одно улучшение заключается в том, что мы добавили возможность определить одно свойство ContentAreaItem. Он выглядит как обычное свойство ContentReference, но предлагает гораздо больше функциональных возможностей.
По сути, он работает как ContentArea с применением ограничения на один элемент.
public virtual ContentAreaItem MyContentItem { get; set; }Также можно ограничить доступные типы контента с помощью Разрешенные типы атрибут
[AllowedTypes(typeof(TeaserBlock), typeof(EditorialBlock), typeof(ContactBlock)]
public virtual ContentAreaItem MyContentItem { get; set; }Пользовательский интерфейс напоминает обычный ContentReference:
Однако, помимо хранения только ссылки, он также позволяет вам создавать и хранить встроенный блок внутри:
Это свойство также будет нормально работать в OPE и будет поддерживать параметры отображения так же, как и в ContentArea (мы повторно используем ContentAreaRenderer).
вопросы и ответы
В: Что происходит после обновления до CMS 12.21.0? Есть ли автоматическая миграция контента?
О: Нет. Это не прорывной релиз. С вашим контентом ничего не случится.
В: Как начать использовать эту новую функцию?
О: Все свойства ContentArea и ContentAreaItem теперь позволяют редакторам создавать встроенные блоки.
Q: Это также поддерживается через API?
О: Да. Все, что вы можете делать в режиме редактирования, поддерживается через наш Management API.
Вопрос. Поддерживает ли ContentArea старые функции?
О: Да, ContentArea по-прежнему поддерживает хранение ContentReference, персонализацию, параметры отображения и т. д.
EPiServer.Labs.BlockEnhancements
Этот пакет уходит. Все его функции теперь являются частью основного пакета. Последней оставшейся функцией является инструмент миграции, описанный выше.
Больше выпусков не будет.
20 июня 2023 г.
