Разработчики часто используют класс COption для хранения и вывода значений каких-либо переменных. И по сути ничего не мешает в этом классе хранить и какие-то переменные сайта/шаблона. Как то: телефон, e-mail и прочие мелкие значения в шаблоне сайта. Часто проблема решается вставкой включаемой области, которую могут править потом редакторы. Но не всегда... [spoiler] Например, в такой ситуации включаемая область мало поможет:
Помещать весь блок кода в одну включаемую область? Не очень красиво. Создавать 3-4 включаемых области? Зачем нам +3-4 доп.файла цеплять? Выход? Хранить все это в вышеозвученном классе. Но как туда записать, и как легко потом менять сие редактору?
Решение и практика
Так родилась идея простого модуля, который бы позволял легко сохранять и выводить такие переменные.
Далее выводим все простой функцией API (о ней ниже):
<?= tplvar('skype');?>
Но это еще не все если у вас есть права на редактирование шаблона и включен режим правки, рядом с каждым значение появится иконка редактирования:
При клике на которую вы переходите к редактированию данной переменной:
Теперь пару слов о функции. Доступна она всегда (после установки модуля) без подключения самого модуля. У нее есть два режима:
1. Для использования голого значения переменной:
<?= tplvar('skype');?>
Например, в коде, или где не требуется вывод иконки даже в режиме редактирования (например, mailto: $var).
Показывает иконку редактирования только в режиме включаемых областей. Хороший пример применения - ссылка на какой-то файл в шапке сайта:
<a href="<?= tplvar('wholesale_pdf');?>">Скачать каталог в PDF</a>
Даже в режиме включаемых областей, нет возможности посмотреть иконку, так как она спрятана в href будет (если быть точным, в данном случае она не выведется вовсе). Поэтому делаем так:
<a href="<?= tplvar('wholesale_pdf');?>">Скачать каталог в PDF</a><?= tplinvis('wholesale_pdf');?>
Имеем иконку, которая появится только в режиме редактирования:
Функция tplvar_set
Применяется для установки значения для определенного кода (например, из API). Использование:
tplvar_set($code, $value, $site);
Все три переменные обязательны: код свойства, значение, ID сайта.
Общие замечания
Модуль работает в рамках текущего сайта (SITE_ID). Вам не надо заботиться о проверке сайта, и одна и та же переменная на разных сайтах может иметь разное значение (например, skype на разных сайтах разный).
Я намеренно сделал вызовы API обезличенными, чтобы партнеры могли применять этот модуль в своей работе не переживая за префиксы чужого партнера.
Алексей, как-то не стал делать этот момент (можно было обойтись стандартным API потому что), но сейчас подумал, что удобнее все же выпустить обертку. Выпустил обновления - установка значения выполняется командой: tplvar_set($code, $value, $site)
Все три поля обязательны (код, значение, ID сайта). Замечу, в админке не существует понятия ID сайта, там надо прописывать значение явно, а не применять константы.
Отличная штука! В качестве развития можно было бы добавить так же "Переменные страницы", думаю из названия понятно в чем особенность этих переменных. =)
Дмитрий, а можно пример когда переменные страницы в таком обличии нужны? Дело в том, что их придется где-то хранить промежуточно, а это уже переменные сайта в чистом виде. (переменные страницы нигде кроме GLOBALS не хранятся, а это только текущий хит)
Антон, например на странице есть области, которые должна быть видны определенным пользователям/группам. Или выборка каких-то записей для определенного круга персон должна быть более широкой... Можно показать менеджеру не имеющему прав на запись страницы настройку в которой он может указать этих пользователей:
Полагаю, что при открытии интерфейса "Переменных страницы" можно использовать тот же функционал, что и для "Переменных сайта", но отображать только переменные с префиксом текущей страницы, например путь_и_имя_файла_ (не показывая сам префикс, конечно)
Ну и при добавлении, соответственно, добавлять переменные с этим префиксом... Вот как-то так я себе это представлял..
Дмитрий, теперь понял, не то сначала думал. Но не до конца понимаю как это упрощает жизнь? Ведь можно переменной присвоить сразу уникальный код. Например, partner_email - email, указанный в партнерском разделе.
А второе замечание добавил в план, подумаю как лучше сделать. Спасибо.
Антон, безусловно вы правы) Сейчас я так и делаю. Просто подумал, что будет удобно иметь отдельную кнопочку, которая покажет переменные относящиеся только к текшей странице (разделу?), а не ко всему сайту в целом. Просто версия. В любом случае спасибо за полезняшку)
Дмитрий, ага, теперь вроде уловил идею. В общем, цель - некая группировка переменных, чтобы, например, открыть сразу все переменные партнерского раздела? Планируется группировка переменных, так как уже сам в работе увидел, что их накапливается много и видеть сразу все в окошке неудобно. Думаю, и вам такая группировка поможет.
Антон, очень граммотный модуль, но согласен с megamosk - по возможности исправьте, пожалуйста, проблему с названиями переменных. Спасибо, в любом случае! P.S. Как можно иметь в Битрикс пользовательские поля и не мочь ими нормально пользоваться - они привязываются к каким-то непонятным "объектам", инфоблокам и т.д. и для их вывода надо использовать кучу кода?!! Ваш модуль - это совершенно логичное дополнение, которое не должно было существовать, ибо разработчики Битрикс игнорят очевидный функционал...
Отличнейшая идея, простое использование (не хватает разве что группирования, да). Но без названий переменнных (а их все нету) смысла в модуле попросту нет...
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».