Представьте себе две колонии боббеков. Обычно это миролюбивые животные, которые живут дружными семьями, но не в ситуациях, когда возникает вопрос о занимаемой ими территории. Это может произойти между редакторами контента и техническими специалистами. Чтобы статья появилась на веб-сайте, вам необходим упрощенный процесс публикации. Редакторы не должны трогать код приложения, а разработчики должны предоставить удобный функционал для публикаций.

Статья предназначена для разработчиков внешних корпоративных веб-сайтов, владельцев сайтов или бизнеса, а также сотрудников, занимающихся внешними коммуникациями. Материал поможет авторам и разработчикам «найти баланс» и обойти неудобные технические проблемы управления контентом на 1С-Битрикс.

Меня зовут Сергей Осокин, я работаю в НЛМК-ИТ и являюсь ведущим внешним разработчиком сайтов группы компаний НЛМК, в которую входят такие сайты, как nlmk.com, Lipetsk.nlmk.com, india.nlmk.com и sgok. nlmk.com и т. д.

При использовании АСУ 1С-Битрикс управление контентом может быть как простой задачей для одного пользователя, так и сложной задачей для десятков контент-менеджеров. В небольших проектах, где пользователь является единственным владельцем веб-сайта, он может легко управлять всем содержимым, заполнять сообщения и редактировать текст из областей включения без Git. В таких случаях все проходит быстро и все участники проекта остаются довольны результатами своей работы.

Однако для крупных проектов, где контентом управляют десятки контент-менеджеров, ситуация может быть более сложной. Здесь весь код хранится в Git, настраиваются процессы разработки и решающее значение имеют запросы на своевременное изменение информации на сайте.

Когда дело доходит до изменения информации в футере или области включения, повторяющейся в разных разделах сайта и хранящейся в репозитории, возникает проблема. Если вы быстро измените эту информацию на сайте, ветка master перестанет быть актуальной и следующий релиз будет запланирован не раньше следующей недели. В такой ситуации возникает вопрос: что делать?

Также возникла необходимость в контент-менеджерах иметь возможность управлять структурой сайта, настройками меню, параметрами SEO (заголовок, описание, ключевое слово) и создавать собственные разделы без изменения физической структуры на сервере. Однако этот функционал в Битриксе жестко привязан к физической структуре на сервере. Мы можем изменить его, только изменив репозиторий.

Использование типовых решений кажется совершенно абсурдным; возникают следующие проблемы:

1. Мы не можем отказаться от использования Git.

2. Встроенные области и файлы index.php могут содержать не только текст, но и PHP-код, для которого у контент-менеджера нет опыта. Опыт показывает, что зачастую они не имеют достаточных знаний о том, как ими пользоваться, что приводит к сбоям в работе системы.

Был проведен анализ и сформулированы требования:

1. Менеджер контента должен иметь ограниченный доступ для изменения файлов PHP.

2. Контент-менеджер должен иметь возможность изменять любой контент на странице.

3. Контент должен быстро меняться

4. Весь код необходимо сохранить в Git.

5. Решение должно учитывать многосайтовость

6. Блоки контента должны быть многократно использованы на разных страницах.

7. Удобный интерфейс.

8. Необходимо быстро менять заголовки страниц, заголовок, описание и ключевые слова. При этом код сайта не должен быть затронут.

9. Необходимо иметь возможность создавать страницы, не прибегая к физической структуре сайта.

10. Создание динамического меню.

По результатам анализа были приняты следующие решения:

1. Разработать собственный модуль управления контентом, где весь контент должен храниться в отдельном блоке загрузки в базе данных.

2. Разработать виртуальную структуру сайта на основе информационного блока с необходимыми свойствами.

Решение первой проблемы

Модель данных для модуля управления контентом:

Для работы с моделью данных используется класс ContentTable.

Внутри класса есть частные свойства $arContentTypes, $arHLBlock и $arHLFields.

Класс содержит следующие статические методы:

— getTableName(): возвращает имя таблицы;

— getMap(): возвращает карту соответствия между полями таблицы и их типами.

Класс также содержит следующие общедоступные методы:

— GetList($arParams = array()): возвращает список элементов по указанным параметрам;

— Подготовка2DB(&$arFields = array(), $method = 'ADD'): подготавливает данные перед сохранением в базе данных;

— AddEx($arFields = array()): добавляет новый элемент;

— Update($id, $arFields = array()): обновляет данные элемента с указанным идентификатором;

— Удалить($id): удаляет элемент с указанным идентификатором;

— getHLBlock(): возвращает массив с информацией о блоке высокой нагрузки;

— 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. Имя в меню – введите String.

3. Ссылка на внешний ресурс – введите String.

4. Редирект на страницу — привязка типа к элементам. Для реализации задачи был создан обработчик, который перебирал файловую структуру на сервере и создавал клон физической структуры в структуре информационного блока. Папка на сервере представляет собой раздел информационного блока, файл index.php представляет собой элемент информационного блока с символьным кодом index.php. Дополнительный агент обновляет структуру, если на сервере что-то изменилось. Пользователи, имеющие право на изменение информационного блока структуры сайта, могут создавать разделы, не привязанные к физической структуре. При создании страницы сайта он сначала проверяет, существует ли такой раздел физически на сервере, и если да, то отображает его. Если такого раздела на сервере нет, но он находится в информационном блоке «Структура сайта», появится виртуальная страница с отображением компонента вывода контента. Этот компонент позволяет контент-менеджеру отображать информацию на странице.

Меню было реализовано таким образом, что оно формировалось не из системных файлов (например, top.menu.php), а из информационного блока «Структура сайта». В свойстве «Отображать в меню» можно выбрать, в каком меню должна отображаться данная запись. В свойстве «Заголовок» в меню вы можете отредактировать заголовок, если он отличается от заголовка. Заголовок и метаданные для SEO берутся из вкладки SEO. Также реализованы дополнительные настройки редиректов и внешних ссылок в меню.

Чтобы упростить заполнение виртуальных страниц, реализованы сниппеты:

1. Аккордеон

2. Инфографика

3. Слайдер

4. Таблица

5. Анонс пресс-релиза

6. Карта лидера

7. Цитата

Такой подход позволил удовлетворить потребности заказчика в своевременном изменении информации при сохранении стабильности основного кода без прерывания процессов разработки. Кроме того, это позволило контент-менеджерам работать над изменениями параллельно, сводя к минимуму риск конфликтов и ускоряя процесс изменений.

Это позволило нам обойти досадные технические проблемы управления контентом на 1С-Битрикс, позволив эффективно управлять контентом и структурой сайта в большом проекте с большим количеством контент-менеджеров.