Как подружить редактора и разработчика: ключевые особенности изменения контента на CMS Bitrix
Представьте 2 колонии байбаков. Обычно это миролюбивые животные, которые живут дружными семьями, но только не в тех ситуациях, когда встает вопрос о занимаемой территории. Подобное может произойти между редакторами контента и техническими специалистами. Чтобы статья появилась на сайте, нужен отлаженный процесс публикации. Редакторы не должны касаться кода приложения, а разработчики должны предоставить удобный функционал для публикаций.
Статья предназначена для тех, кто занимается разработкой внешних сайтов компании, владельцам сайтов или бизнеса, а также сотрудникам, занимающимся внешними коммуникациями. Материал поможет «найти баланс» писателям и разработчикам и обойти последним неудобные технические проблемы в управлении контентом на 1С-Битрикс.
Меня зовут Сергей Осокин, я работаю в НЛМК-ИТ и являюсь ведущим разработчиком по внешним сайтам группы компаний НЛМК, в которые входят такие сайты как nlmk.com, lipetsk.nlmk.com, india.nlmk.com, sgok.nlmk.com и др.
При использовании 1С-Битрикс БУС управление контентом может представлять собой как простую задачу для одного пользователя, так и сложную задачу для десятков контент- менеджеров. В небольших проектах, где пользователь является единственным владельцем сайта, он может легко управлять всем контентом, заполнять новости и редактировать тексты из включаемых областей без использования Git. В таких случаях все происходит оперативно, и все участники проекта остаются удовлетворенными итогами своей работы.
Однако, в случае больших проектов, где контентом управляют десятки контент-менеджеров, ситуация может быть более сложной. Здесь весь код хранится в Git, настроены процессы разработки, а запросы на оперативность изменения информации на сайте имеют критическую важность.
Когда речь идет об изменении информации в футере или во включаемой области, которая повторяется в разных разделах сайта и хранится в репозитории, возникает проблема. Если оперативно изменить эту информацию на сайте, то ветка master перестанет быть актуальной, а ближайший релиз запланирован только на следующей неделе. В такой ситуации возникает вопрос — что делать?
Также возникла потребность, чтобы контент менеджеры, могли управлять структурой сайта, настройками меню, SEO параметрами (title, description, keyword) и создавать свои разделы, не изменяя физическую структуру на сервере. Но этот функционал в Bitrix жестко привязан к физической структуре на сервере. Изменять ее мы можем только изменяя репозиторий.
Использование типичных решений представляется полным абсурдом, возникают следующие проблемы:
1. Отказаться от использования Git мы не можем.
2. Во включаемых областях и файлах index.php может быть не только текст, а еще какой-то php код, в котором у контент-менеджера нет компетенции. Опыт показывает, что часто они не имеют достаточных знаний для работы с ним, что приводит к сбоям в работе системы.
Был проведен анализ и сформулированы требования:
1. У контент-менеджера должен быть ограничен доступ к изменению php файлов
2. У контент-менеджера должна быть возможность изменять любой контент на странице
3. Контент должен меняться оперативно
4. Весь код должен храниться в Git
5. Решение должно учитывать многосайтовость
6. Блоки контента должны иметь возможность переиспользования на разных страницах
7. Удобный интерфейс
8. Необходимо оперативно менять заголовки страниц, title, description, keywords. При этом код сайта не должен затрагиваться
9. Необходимо иметь возможность создавать страницы, не прибегая к физической структуре сайта
10. Динамичное создание меню
По итогу анализа были приняты решения:
1. Разработать собственный модуль управления контентом, в котором весь контент должен храниться в базе данных в отдельном highload-block.
2. Разработать виртуальную структуру сайта на основе инфоблока с необходимыми свойствами.
Решение первой задачи
Модель данных для модуля управления контентом:
Для работы с моделью данных используется класс ContentTable.
Внутри класса есть приватные свойства $arContentTypes, $arHLBlock и $arHLFields.
Класс содержит следующие статические методы:
— getTableName (): возвращает имя таблицы;
— getMap (): возвращает карту соответствия полей таблицы и их типов.
Класс также содержит следующие публичные методы:
— GetList ($arParams = array ()): возвращает список элементов с учетом указанных параметров;
— Prepare2DB (&$arFields = array (), $method = 'ADD'): подготавливает данные перед сохранением в базу данных;
— AddEx ($arFields = array ()): добавляет новый элемент;
— Update ($id, $arFields = array ()): обновляет данные элемента с указанным идентификатором;
— Delete ($id): удаляет элемент с указанным идентификатором;
— getHLBlock (): возвращает массив с информацией о highload-блоке;
— getHLFields (): возвращает массив с информацией о полях highload-блока;
— getContentTypes (): возвращает массив с информацией о типах контента;
— getContentTypeID2Code (): возвращает массив, который сопоставляет идентификаторы типов контента с их кодами;
— getContentTypeCode2ID (): возвращает массив, который сопоставляет коды типов контента с их идентификаторами.
Вывод контента будет регулироваться разработанным компонентом. Его можно будет разместить в любом месте страницы (Шаблон, подключаемый файл или index.php). Можно рассчитать заранее, где возможно понадобиться размещать контент.
Ниже приведено описание основных методов компонента CIContentComponent:
1. onIncludeComponentLang (): Метод вызывается перед включением языковых файлов компонента. В ней можно определить языковые сообщения, которые будут использоваться в компоненте.
2. onPrepareComponentParams ($params): Метод вызывается перед выполнением компонента и позволяет подготовить параметры компонента перед их использованием. В ней можно производить проверку и преобразование параметров.
3. executeComponent (): Основной метод компонента, который выполняет все необходимые действия для получения и обработки данных. В этой функции можно вызывать другие функции класса и формировать результат работы компонента.
4. checkModules (): Метод проверяет наличие необходимых модулей для работы компонента. Если какого-либо модуля нет, то метод может вывести сообщение об ошибке или выполнить другие действия.
5. checkParams (): Метод проверяет наличие необходимых параметров компонента. Если какого-либо параметра нет или он имеет неверное значение, то метод может вывести сообщение об ошибке или выполнить другие действия.
6. executeProlog (): Функция выполняет какие-либо действия перед выполнением компонента. Например, она может устанавливать заголовок страницы или добавлять CSS и JS файлы.
7. readDataFromCache (): Метод пытается получить данные из кэша. Если данные есть в кэше, то метод возвращает их. Если данных в кэше нет или они устарели, то метод возвращает false.
8. getResult (): Метод формирует результат работы компонента. В ней можно производить необходимые вычисления и подготавливать данные для вывода.
9. putDataToCache (): Метод сохраняет данные в кэш. Данные могут быть сохранены с определенным ключом и с дополнительными параметрами.
10. showEditButtons (): Метод отображает кнопки редактирования компонента, если пользователь имеет соответствующие права доступа.
11. executeEpilog (): Метод выполняет какие-либо действия после выполнения компонента. Например, она может удалять временные файлы или освобождать ресурсы.
12. abortDataCache (): Метод отменяет сохранение данных в кэш и очищает кэш, если он был создан.
Управлять контентом можно из публичной части
Также можно что-то изменять или добавлять в административной части.
Таким образом контент-менеджерам такие файлы, как index.php и включаемые области, теперь будут недоступны для изменений. Это позволит обеспечить безопасность и стабильность работы системы. В то же время контент-менеджерам предоставлен удобный интерфейс для изменения контента в режиме правки публичной части сайта. Теперь контент менеджеры смогут легко и быстро вносить необходимые изменения в контент, не прибегая к изменению php файлов. Это значительно упростит процесс работы и повысит эффективность работы контент-менеджеров.
Решение второй задачи
Была принята идея, создать виртуальную структуру на основе инфоблока. Ниже перечислены дополнительные свойства этого инфоблока:
1. Отображать в меню — Тип Список
2. Название в меню — Тип Строка
3. Ссылка на внешний ресурс — Тип Строка
4. Редирект на страницу — Тип Привязка к элементамЧтобы реализовать задачу, был создан обработчик, который проходил по структуре файлов на сервере и создавал клон физической структуры в структуре инфоблока. Папка на сервере это раздел инфоблока, файл index.php это элемент инфоблока с символьным кодом index.php. Дополнительный агент актуализирует структуру если что-то изменилось на сервере. Пользователи, которые имеют право на изменения инфоблока структура сайта, могут создавать разделы, которые не имеют привязки к физической структуре. При формировании страницы сайта, сначала проверяется есть ли физически такой раздел на сервере и если есть, то выводит ее. Если такого раздела нет на сервере, но в инфоблоке Структура сайта он есть, то выводится виртуальная страница на которой выводится компонент вывода контента. Контент-менеджер может вывести на странице информацию с помощью этого компонента.
Меню было реализовано таким образом, чтобы оно формировалось не из системных файлов (например, top.menu.php), а из инфоблока Структура сайта. В свойстве «Отображать в меню» можно выбрать в каком меню выводить данный пункт. В свойстве Название в меню можно отредактировать название, если оно отличается от заголовка. Заголовок и мета данные для SEO, берутся из вкладки SEO. Также были реализованы дополнительные настройки для редиректов и внешних ссылок в меню.
Для удобства наполнения виртуальных страниц были реализованы сниппеты:
1. Аккордеон
2. Инфографика
3. Слайдер
4. Табы
5. Анонс пресс-релиза
6. Карточка руководителя
7. Цитата
Такой подход позволил удовлетворить потребности заказчика в оперативном изменении информации, сохраняя при этом стабильность основного кода и не нарушая процессы разработки. Кроме того, это дало возможность контент-менеджерам работать над изменениями параллельно, минимизируя риски конфликтов и ускоряя процесс внесения изменений.
В итоге мы обошли неудобные технические проблемы управления контентом на 1С-Битрикс, тем самым дав возможность эффективно управлять контентом и структурой сайта в большом проекте с большим количеством контент-менеджеров.
