Практически на каждом проекте есть вот такого рода блоки, которые непонятно как интегрировать в CMS, чтобы сохранить возможность редактирования клиентом в будущем:
Прежде чем идти дальше, прикиньте для себя, как бы вы решали эту задачу. Этот пост носит еще обучающий характер.
А какие вообще варианты есть?
Взять html-код и запихать его во включаемую область. Минусы - при редактировании клиент может повредить верстку, а также заставить испытать его сложности (непонятно как править кусок кода).
Завести инфоблок. Но один инфоблок на один блок это слишком круто.
Использовать точечные переменные, но для блока на скрине выше потребовалось бы аж 4 раза кликать на одиночные переменные. Трудно для клиента.
Запилить компонент. Тут каждый столкнется с ленью - как мол так, на один простой блок, целый компонент.
Я решил пойти по последнему варианту, но раз и навсегда решить вопрос с ленью. А именно сделать универсальную болванку.
Которая:
Не доставит сложностей разработчику для внедрения. Не будет лени другими словами.
Оставит все удобства для редактирования клиентом.
Компонент получился состоящим, фактически, из шаблона. Одна "включаемая область" это один шаблон. А компонент один на всех. В чем магия? А магия в .parameters.php каждого из шаблонов, внутри которого мы и определеяем переменные. Но даже тут я предвидел лень, и поэтому свел все к копипасту и линейному массиву:
То есть, вы правите ТОЛЬКО верхний блок, добавляя столько переменных, сколько требуется шаблону. Для скрина во вступлении я сделал 4 переменных. Каждая из них превратилась в мини-текстареа, чтобы можно было ввести в случае чего и многострочный текст.
Все, в шаблоне теперь доступны все эти переменные, и ими можно управляться как-то так (оцените сложный html-код вокруг):
Вот и вся наука. Еще раз, план действий для реализации такого блока:
Качаем компонент с этого поста.
Размещаем его в пространство компонент asd (ну или свой по желанию).
Создаете в папке шаблонов компонента еще один по аналогии, в .parameters.php шаблона по аналогии создаете свои переменные, правите шаблон, вставляя ваш блок.
В нужное место сайта вставляете вызов компонента: <?$APPLICATION->IncludeComponent('asd:variable.set', 'test');?>
Может, всё таки инфоблок?
Если менять параметры компонента, изменится файл php его вызывающий. А попадет ли он в систему контроля версий?
Мне кажется, проще сделать на инфоблоках, чем внедрять github в панель админа.
Не обязательно. Можно сделать один инфоблок для нетиповых элементов.
Добавить свойство, например PARAMS, закастомить страницу редактирования элемента и по switch, ng-show, ng-hide или ещё как-нибудь выводить поля, а перед сохранением паковать в json и хранить в PARAMS.
Так вам точно не придется за клиентом отслеживать изменения и кидать их в контроль версий.
Пардон, все равно не понял я предполагаю, что клиент НЕ добавляет блоков, они создаются при создании проекта. Он лишь меняет в них информацию. То есть файлы добавляться не будут клиентом. (если речь про это)
Именно по этой же причине еще раз не вижу смысла в ИБ - кнопка "добавить новый элемент" становится бессмысленной. Появляются лишние вопросы "а что будет".
Или речь про то, что сохраняемые настройки меняют целевой файл?
Я делаю так. К примеру, страница контактов у меня со сложной версткой, я внедряю на эту страницу одну включаемую область: http://prntscr.com/bogyda Обратите внимание на выделенный параметр, он позволит скрыть возможность редактирования ЭТОЙ области.
Внутри области я размещаю уже компоненты и другие включаемые области (в том числе и компонент из поста) http://prntscr.com/bogysn
Резюмируя, можно самую первую включаемую область размещать в том же /local
подход Переменные сайта - лучше все значения в одном месте без дублирования.
просто надо както улучшить представления для редактирования - например при включенном режиме редактирования
выводить все доступные поля для редактирования сразу а не в попапе.
вообще битриксу давно пора внедрить инлайн редактирование из коробки.
> А магия в .parameters.php каждого из шаблонов
а так это значит можно прописать и использовать эти же параметры в стандартном компоненте "подключаемая область" и не делать свой компонент?
или свой компонент обязателен для такого рода параметров?
По факту - в main.include (про него же речь?) идут еще какие-то проверки (кстати, которые могут вхолостую выполняться, если вы случайно не тот параметр добавите). Я не говорю, что это огого как страшно, но зачем мне к примеру в хидере каком-нибудь лишние пару проверок. Поэтому предпочитаю простое и прозрачное решение (для себя).
Здравствуйте, а можно добавить выбор файлов к форме редактирования параметров ? т.е чтоб клиент кроме текстовых данных мог прикрепить несколько ссылок на фото ?) как такое можно реализовать ?
В теории можно прилепить выбор файла на JS - точнее вызов диалога. Как вариант, спросить ТП Битрикс - может есть какой-то уже компонент с данным типом св-ва, который вам нужен.
Это все относится к параметрам компонента, а не конкретно к описанному здесь.
Решение - супер!
Я обычно это все включаемыми файлами оставляю, или выношу в настройки модуля, если какая-то общая информация, вроде номера телефона или еще что-то такое, что нужно на каждой странице сайта...
Надо чтобы номер телефона выводить не один раз тк может быть их 3 и даже 5.
при добавлении указать сам номер телефона и описание его.
создавать по 10 полей под каждый не разумно.
можно ли как-то сделать чтобы добавление могло быть множественное с указанием этих полей для телефона и также остальные без проблем можно было.
А как правильно организовать доступ пользователю (контент-менеджеру) к такому компоненту? Если дать доступ на всю страницу - есть шанс что он её отредактирует вместе с компонентом:)
Ого, спасибо за столь оперативный ответ:)
Сейчас я делаю так: создаю включаемую область, внутри у нее подключаю компонент, на файл области даю доступ группе контент-менеджеров. Но, думал, может существует иной подход к организации прав доступа.
Вот все-таки удобно сделали в Тильде редактирование такой информации. Может быть тоже как можно сделать через Сайты24... А если еще несколько языков, то неудобно клиенту. Одну информацию заполняй через инфоблоки, потому что там информации заполнять надо много, другую через файлы языковые, третье через настройки компонентов, четвертое через включаемые области. Жесть конечно.
За идею спасибо, Антон. Всегда радовали ваши решения.
Если менять параметры компонента, изменится файл php его вызывающий. А попадет ли он в систему контроля версий?
Мне кажется, проще сделать на инфоблоках, чем внедрять github в панель админа.
Добавить свойство, например PARAMS, закастомить страницу редактирования элемента и по switch, ng-show, ng-hide или ещё как-нибудь выводить поля, а перед сохранением паковать в json и хранить в PARAMS.
Так вам точно не придется за клиентом отслеживать изменения и кидать их в контроль версий.
Именно по этой же причине еще раз не вижу смысла в ИБ - кнопка "добавить новый элемент" становится бессмысленной. Появляются лишние вопросы "а что будет".
Я делаю так. К примеру, страница контактов у меня со сложной версткой, я внедряю на эту страницу одну включаемую область:
Внутри области я размещаю уже компоненты и другие включаемые области (в том числе и компонент из поста)
Резюмируя, можно самую первую включаемую область размещать в том же /local
Не?
подход Переменные сайта - лучше все значения в одном месте без дублирования.
просто надо както улучшить представления для редактирования - например при включенном режиме редактирования
выводить все доступные поля для редактирования сразу а не в попапе.
вообще битриксу давно пора внедрить инлайн редактирование из коробки.
веть там могут быть разные наборы
а так это значит можно прописать и использовать эти же параметры в стандартном компоненте "подключаемая область" и не делать свой компонент?
или свой компонент обязателен для такого рода параметров?
Как использовать файл параметров в шаблоне можно глянуть в примере к посту - я там прикрепил компонент с шаблонами.
У самого компонента может вообще файл параметров отсутствовать.
попробовал скопировать файл в шаблон компонента "Включаемая область" и параметры появились - офигенная фича битрикса о которой только сейчас узнал.
еще один аргумент в пользу ипользования стандартных компонентов
По факту - в main.include (про него же речь?) идут еще какие-то проверки (кстати, которые могут вхолостую выполняться, если вы случайно не тот параметр добавите). Я не говорю, что это огого как страшно, но зачем мне к примеру в хидере каком-нибудь лишние пару проверок. Поэтому предпочитаю простое и прозрачное решение (для себя).
Вот дока
В теории можно прилепить выбор файла на JS - точнее вызов диалога. Как вариант, спросить ТП Битрикс - может есть какой-то уже компонент с данным типом св-ва, который вам нужен.
Это все относится к параметрам компонента, а не конкретно к описанному здесь.
Я обычно это все включаемыми файлами оставляю, или выношу в настройки модуля, если какая-то общая информация, вроде номера телефона или еще что-то такое, что нужно на каждой странице сайта...
Делал всегда через включаемые области, но при корявом заполнении все уезжало.
Автор молодец!
пример 1 поля: +8 800 123-12-12 (основной номер) - номер телефона и само описание
и это чтобы можно было сделать несколькими данными
Номер:
Описание номера:
Если я правильно понял вопрос.
при добавлении указать сам номер телефона и описание его.
создавать по 10 полей под каждый не разумно.
можно ли как-то сделать чтобы добавление могло быть множественное с указанием этих полей для телефона и также остальные без проблем можно было.
Больше идей нет.
Сейчас я делаю так: создаю включаемую область, внутри у нее подключаю компонент, на файл области даю доступ группе контент-менеджеров. Но, думал, может существует иной подход к организации прав доступа.
За идею спасибо, Антон. Всегда радовали ваши решения.
Если нужно множественное поле, например для телефонов:
P.S. Спасибо за решение! Раньше иногда делал включаемые области с кастомными шаблонами и доп.параметрами, но сделать такой компонент руки не доходили.