Предлагаю здесь коротенечко поделиться почему надо использовать lang-файлы, или не надо. Речь не о партнерских решениях Маркетплейса - там строго обязательно, а индивидуальные компоненты, и, конечно же, шаблоны.
Отвечу за себя. Раньше писал в ланг-файлы, потом понял, что время на разработку тратится все равно больше, а вероятность что каждый сайт будут переводить - ничтожно мала. Если есть вероятность - конечно пишу ланг-файлы.
Теперь в шаблонах не применяю ланг-фразы. Во-первых (на данный момент), до ланг-фраз сложно добраться потом, чтобы поправить какую-то деталь. Во-вторых, без модуля локализации в эти файлы не хорошо вообще лезть редакторам.
В компонентах выношу в ланг-файлы, просто потому что это системная часть и там хотелось бы видеть порядок. К тому же, никогда не знаешь с какой кодировкой в IDE ты срочно полезешь править компоненту (не увидишь и сохранишь не в той, и конец).
There are times when you need to hide folders. <a href="; How to show hidden files and folders </a> .Open the explorer, it is “This computer”. Click the “View” tab and tick the “Hidden items”. If you do not have the “View” tab, then drag the window wider and it will appear.
В данном посте опишу не столько решение (хотя, оно довольно востребованное), сколько подход к использованию того что есть и без лишних лисапедов. Итак, задача - сделать красивую форму авторизации на AJAX, которая бы без перезагрузки страницы проверяла валидность логина/пароля, выводила ошибки, и авторизовывала.
Сначала я думал оформить это как решение, но в итоге бы получился очередной лисапед - я не встречал еще ни одного проекта, где такого рода компоненты вставали без кастомизации. Поэтому, посидел, подумал, и представляю, на мой взгляд, красивый подход к решению задачи.
За основу берем стандартный шаблон компонента system.auth.form, который я переделал на выпадашку (было даже в каком-то это дело).
Правим под свой стиль, кастомизируем как угодно. Чтобы работало. Теперь пришло время вешать аякс. Разумеется, сначала подключаем jquery (я до сих пор не люблю jquery из коробки, так как наши спохватились поздно, и каждый проект уже оброс своими библиотеками jquery, а винегрет из них я не хочу).
Я не вносил никаких изменений в стандартную форму, кроме как окружил ее дивом login-area. Ели она у вас уже кастомизирована, то проверьте наличие атрибута action. Да и по сути все.
Иду по порядку так, как рождалась идея. Итак, сначала я накидал js-код
<sc ript type="text/javascript">
$(docu ment).on('ready', f unction(){
$('#login-area form').submit(f unction(){
var $this = $(this);
var $form = {
action: $this.attr('action'),
post: {'ajax_key':'<?= md5('ajax_'.LICENSE_KEY)?>'}
};
$.each($('input', $this), f unction(){
if ($(this).attr('name').length) {
$form.post[$(this).attr('name')] = $(this).val();
}
});
$.post($form.action, $form.post, f unction(data){
$('input', $this).removeAttr('disabled');
if (data.type == 'error') {
a lert(data.message);
} else {
window. location = wind ow. location;
}
}, 'json');
return false;
});
})
</sc ript>
Что делает код (небольшой урок по jquery заодно, так сказать): 1. Слушаем сабмит формы, и если он происходит, вклиниваемся в него. 2. Создаем переменные для удобства. Об ajax_key я расскажу ниже. 3. Бежим по всем input, и кидаем их в массив для отправки. 4. Собственно, отправляем данные, ответ принимаем как json. Получаем ответ и обрабатываем его. Если ошибки - выводим их, если все ок - рефрешимся сами на себя (мне этого хватило, но вы можете, например, вывести сообщение об успешно авторизации и скрыть форму)
Код написан, но вот как поулчать ответ без лисапедов, лишних скриптов и прочего? Решение пришлось легко и красиво.
Мы шифруем лицензионный ключ и передаем его в форме. И в этом же шаблоне формы авторизации, проверяем этот ключ, и если он есть и верен, то отдаем данные в формате json. Проверка на ключ нужна по одной причине - чтобы "злоумышленник" не получил лишний раз пустую страницу, передав какой-нибудь ?ajax=Y
1. RestartBuffer - так как страница уже начала выполняться (форма же у вас в шаблоне), то надо сбросить буфер. 2. PUBLIC_AJAX_MODE на всякий случай уберем лишний мусор (такой как "отладка страницы" и прочее). 3. Если форма сработала с ошибкой, то отдаем ошибку как json-объект, иначе говорим, что все ок. 4. Выходим.
Есть одна недоработка, которую я не сделал, так как мне не требовалось - не учитывается защищенная авторизация и пароль передается в открытом виде. Я даже не смотрел как это реализуется, поэтому, если кто-то дополнит код на этот случай, включу в пост.
Естественно, по аналогии вы можете реализовать любую форму - регистрации, восстановления пароля, и прочие.
PS: Убирайте лишние пробелы в коде, вставленные парсером.
Сначала о проблеме с которой я столкнулся. Понадобилось добавить новую вкладку в соцсети, но с возможностью ее настройки. Ну, грубо говоря, вы выпускаете партнерское решение, которое добавляет вкладку с новостями в соцсеть. Все бы хорошо, но копий соцсети может быть несколько, даже в рамках одного сайта. И с какого именно инфоблока выводить во вкладке - не вынести в настройки модуля. В общем, кто лазил, тот поймет уныние ситуации
Решение - только настройки компонента соцсети. Но как быть, если мы не оперируем шаблоном соцсети, а только ее отдельной вкладкой?
Помогла фича продукта, при которой шаблона может и не быть, а быть только дополнительный .parameters.php и все. Системный компонент его подхватит и дополнит свои настройки настройками из него.
Размещаем в /bitrix/templates/.default/components/bitrix/socialnetwork/.default единственный файл .parameters.php с нужными нам настройками и получаем нужное нам расширение:
Если кто забыл какие внутренности у файла .parameters.php:
Большое спасибо, Антон, за пример! Как правильно заметил Андрей, в документации не указана переменная $arTemplateParameters - кучу времени убил, чтобы разобраться, почему дополнительные параметры не подтягиваются. Битриксу как всегда двойка в этой области.
Долганин Антон написал: под рукой. Вот требуется вам сохранять элемент со свойством, передавая просто название элемента списка, и не париться о том, есть ли такой вариант, или надо добавить н
Да это старо как битрикс! А вот как сделать если ты хочешь добавить в шаблон bitrix:catalog кроме стандартного набора еще один компонент и при этом использовать настройки комплексного компонента ($component), но не просто вынести эти настройки во вкладку "Дополнительно", а создать свою вкладку, по аналогии с существующими (настройки ТОПа или "С этим товаром покупают")??? Вот это как реализовать? Как добавить свою группу в параметрах шаблона?
Дело в том, что именно первая строчка выплевывает jquery системный, а вторая строчка js-скрипты шаблона (которые по правильному должны подрубаться через AddHeadScript). Таким образом, если их поменять местами, сначала пойдут скрипты, использующие jquery, а затем сама jquery. Конечно же, jquery это лишь пример подводного камня.
PS: Такой же порядок в
<?$APPLICATION->ShowHead();?>
но мне метод не нравится в силу того, что я не могу сам раскидать теги как мне надо.
Не путайте людей, сейчас через настройки можно выносить все js вниз страницы, а их порядок зависит от порядка их регистрации в шаблоне.
В 90% случаев подключаете первую jquery и подобные библиотеки и патом всё остальное и никаких проблем не будет, а если всё же есть то вы изобрели велосипед.
Я думаю это очевидно должно быть, что строка идет Выше, потому что как раз в ней часто вызывается jquery с гугла.
А вот у меня назрел вопрос, есть ли реальная разница между Asset::getInstance()->addString(""); и $APPLICATION->ShowHeadStrings(); в скоросрти работы, и не отвалится ли $APPLICATION в одном из обновлений битрикса, в результате полного перехода на D7.
Столкнулся с довольно странным поведением (сначала думал) продукта, убил прилично времени. Так что, поделюсь этими граблями. Грабли относятся к БД с транзакциями (INNODB в MySQL, в частности).
Суть - пытаемся записать в Журнал сообщение при добавлении поста в форум. В данном виде все отлично работает. Но стоит нам откомментировать две нижние строчки, как ничего не добавляется - автоинкремент таблицы Журнала увеличивается, но лог не пишется. Это сейчас на простейшем обработчике 2 + 2 связываются легко, но стоило времени дойти до этого
В чем магия? Дело в том, что добавление постов в форум (а может и в блоги) окружено такой конструкцией в компонентах:
StartTransaction
AddMessage()
Commit OR RollBack
Для непосвященных, основная фишка транзаций - все-все что мы делаем после StartTransaction, упадет в базу только после Commit. Если же делается RollBack, то ничего не добавится. Вообще ничего.
И вот в эти грабли я и попал - в AddMessage генерировалась ошибка, а далее (в компоненте) делался RollBack. Соответственно, запись не ложилась в таблицу.
А можно ли закрывать транзакцию, если ее не открывать? У тебя получается $GLOBALS['DB']->RollBack(); дважды. Один ты закрыл, a другой, наверняка, еще где-то.
Артемий, все можно, только будет ли толк )) тоже самое можно сказать человеку закрыть два раза дверь не открывая, он команду получит, но ничего делать не будет, т.к. дверь уже закрыта =)
Наверное, никто не будет спорить, что форма оформления заказа это самый сложный элемент для кастомизации, так как если внешний облик формы не устраивает клиента, то попотеть придется. Как-то так:
Поэтому, я поделюсь кое-какими соображениями о самой сложной части кастомизации - о блоке свойств. И да, речь пойдет исключительно об одношаговом компоненте как самом ходовом и современном. Много я шишек набил на этих формах, много шагов было сделано неправильных. Вот какие правила я вынес:
1. Нельзя писать свою форму (свою логику). Ой поплачете. За прошлые годы я свидетель как эта форма меняется раз в квартал стабильно. Меняются алгоритмы, добавляются события, на которые вешаются сторонние решения Маркета. В общем, не лезьте туда. Выносить и менять логику - ну если прямо , то можно.
2, Если форма сложная, то по части свойств предусмотреть универсальность практически нельзя. Да, вы конечно будете несомненно крутым интегратором, если сделаете сабж выше универсальным, который бы подстраивался под новые свойства. Но мой вам совет - тоже не стоит. Даже если в такой форме добавится "телефон соседей", то ее придется дорисовать сначала, потом утвердить, а потом снова "доинтегрировать". Я рекомендую такие формы заранее обговаривать с клиентом и объяснять ему, что так мол и так.
3. Есть еще вариант говнокдинга (тоже пройденный, несомненно), когда мы ставим кучу if'ов, чтобы знать в каком месте html вывести то или иное свойство. Были чужие варианты и пострашнее, когда в форму, какая она есть от верстальщика, вставляешь name="ORDER_PROP_123", где 123 завтра может смениться и всему конец. Динамика должна остаться хотя бы в именовании полей.
4. Контролируйте и учите верстальщика. Об этом в самом конце.
Посему, от п.2 мы и оттолкнемся (и не забудем про п.3). Итак, смотрим на верстку, и видим, какие свойства нам надо создать. То есть то, что является именно свойствами
Создаем их, с чувством, с толком, с расстановкой. Вот так они выглядят в шаблоне visual без кастомизации (кстати, этот шаблон вышел недавно, и рекомендую использовать впредь всегда его). placeholder'ы, которые вы видите на первом скрине, я поместил в поле "описание" свойств.
Копируем шаблон на редактирование и идем во внутренний файл шаблона props.php. Там находим блок вывода свойств. Это происходит в два шага - первый это те свойства, которые не входят в профиль, и заполняются каждый раз снова и снова. Второй - свойства, которые могут быть сохранены в профиле. Так как такая форма не предполагает первый вариант, мы его убираем. Ну и все свойства вам конечно надо создавать с галочкой "сохранять в профиле".
Далее перемещаемся в самый верх функции PrintPropsForm, которая расположена здесь же, и пишем там буферизацию куска html, отвечающего за блок свойств.
Кусок html представляет из себя обычный html, где вместо полей формы мы пишем маркеры с кодами свойств (#КОД_СВОЙСТВА#).
Весь этот блок у нас в переменной $props, который надо вывести в аккурат после foreach, который идет далее.
Промежуточный результат у нас какой-то такой
Теперь, в самом начале блока foreach нам надо вставить переопределение нужных полей. Мне нужны были только TEXT и одна TEXTAREA. Руководствуясь пунктом 2 на остальные свойства забиваем. Потом ставим continue и что дальше происходит - нас не волнует.
То есть, еще раз - мы берем и заменяем маркеры в буферизированном блоке на живые поля ввода, такие, какие они были бы в нормальном выводе. Получаем результат полностью рабочий.
Какое правило мы еще отсюда вынесли? То самое - правило 4. То, что верстальщик должен быть в теме, а лучше работать бок-о-бок с интегратором. Верстальщик сей верстки был профессиональным, поэтому не стал каждому инпуту давать свой индивидуальный класс, даже поле индекса не имеет ни отдельного класса, ни size="4". Респект! Что позволило нам максимально быстро и чисто интегрировать верстку в форму.
К посту я прикрепляю файл props.php, где вы можете посмотреть пример кода из урока. Он конечно еще не закончен (для данной верстки), я намеренно оставил его таким для примера.
А я использую компонент по шагам bitrix:sale.order.full и в нем нет файла props.php зато есть функция PrintPropsForm Есть варианты как отсортировать свойства по группам?
Дмитрий, не смотря на то, что это многошаговый, св-ва и так по группам должны идти (а иначе как?). Возможно ошибка какая-то, рекомендую в Битрикс стукнуть.
Зачем заменять маркеры в буферизированном блоке на живые поля ввода, если потом просто ставить continue? Не претендую на истину последней инстанции. Мне просто хочется разобраться.
Для выполнения каких-либо действий в назначенный момент в Битриксе используются агенты: и .
Агенты названы крайне неудачно "периодические" и "непериодические". Разберём, какие реально бывают агенты.
Агент - это запись в специальной таблице:
какой код надо выполнить,
когда выполнить,
с каким периодом выполнять,
каким способом назначать время следующего запуска агента (периодический или непериодический агент).
Обычно, когда пользователь зашел на страничку сайта, ядро Битрикса смотрит, есть ли агенты, время которых наступило и выполняет их.
Важно. В начале хита еще не объявлена переменная $USER. Её в агентах использовать нельзя.
Можно в агенте создать объект $USER, что-то с ним сделать и уничтожить.
Реальное время запуска агента обычно чуть-чуть позже, чем время, на которое назначен агент. Момент запуска — это когда кто-то зашел на страницу сайта.
Настройки -> Настройки продукта -> Агенты:
Агенты, прежде всего, бывают повторяющиеся или неповторяющиеся. Это зависит от программиста, который написал код агента.
Если функция агента возвращает вызов себя, то агент повторяется.
Если функция агента ничего не возвращает, то агент будет удален из таблицы и больше не запустится. Агент не повторяется.
Программист может сделать агента, который повторится бесконечное число раз. Или только 2-3 раза в зависимости от условий. В списке агентов это увидеть нельзя. Только смотреть в код.
Пример функций агентов повторяющихся бесконечное число раз:
// пример функций агентов
function TestAgentPeriod()
{
AddMessage2Log( "Периодический BX_CRONTAB:".BX_CRONTAB." BX_CRONTAB_SUPPORT:".BX_CRONTAB_SUPPORT );
return "TestAgentPeriod();";
}
function TestAgentNotPeriod()
{
AddMessage2Log( "Непериодический BX_CRONTAB:".BX_CRONTAB." BX_CRONTAB_SUPPORT:".BX_CRONTAB_SUPPORT );
return "TestAgentNotPeriod();";
}
Вычисление следующего времени запуска.
Для повторяющихся агентов есть смыл говорить об интервале запуска и способе вычисления времени следующего запуска.
В данном примере интервал агентов 15 секунд. Один агент периодический, а другой непериодический.
Назначенное время следующего запуска периодического агента вычисляется так:
Старое назначенное время агента + интервал.
Этот способ позволяет запустить агент точное число раз. Например, раз в день запускается агент очистки старых почтовых событий или агент с ежедневным отчетом о посещаемости сайта.
Назначенное время следующего запуска непериодического агента вычисляется так:
Время завершения последнего запуска агента (выполнение return агента) + интервал
Абсолютное большинство агентов непериодические.
Например, агент пересчета рейтингов запускается раз в час. Но если за сутки не было ни одного посетителя, то логичнее выполнить агент один раз и сдвинуть назначенное время следующего запуска на час вперед после запуска. В случае периодического агента, этот код выполнился бы 24 раза за все сутки.
Агенты могут запускаться не только на хитах пользователя, но и . Но, как это правильно настроить, — тема .
Старицин Геннадий, если агент периодический и время следующего запуска у него 15:00:00, то после 15:00:00 Битрикс попытается его запустить. И неважно сколько времени агент будет работать. Если интервал один час, то время следующего запуска будет назначено 16:00:00.
-----------
Если агент непериодический и выполняется 5 минут, то всё сложнее.
Допустим хит пользователя (или крон) пришел в 15:01:00, агент реально запустился в 15:01:00 и закончил работу в 15:06:00. Тогда время следующего запуска непериодического агента 16:06:00.
------------
Поэтому я предлагаю называть агенты так. Повторяющиеся и неповторяющиеся.
Повторяющиеся бывают:
Периодические - это строго периодические. Непериодические - это нестрого периодические.
Для неповторяющихся одноразовых агентов разницы периодический или непериодический почти нет.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
There are times when you need to hide folders. <a href="; How to show hidden files and folders </a> .Open the explorer, it is “This computer”. Click the “View” tab and tick the “Hidden items”. If you do not have the “View” tab, then drag the window wider and it will appear.