Дело в том, что именно первая строчка выплевывает jquery системный, а вторая строчка js-скрипты шаблона (которые по правильному должны подрубаться через AddHeadScript). Таким образом, если их поменять местами, сначала пойдут скрипты, использующие jquery, а затем сама jquery. Конечно же, jquery это лишь пример подводного камня.
PS: Такой же порядок в
<?$APPLICATION->ShowHead();?>
но мне метод не нравится в силу того, что я не могу сам раскидать теги как мне надо.
Не путайте людей, сейчас через настройки можно выносить все js вниз страницы, а их порядок зависит от порядка их регистрации в шаблоне.
В 90% случаев подключаете первую jquery и подобные библиотеки и патом всё остальное и никаких проблем не будет, а если всё же есть то вы изобрели велосипед.
Я думаю это очевидно должно быть, что строка идет Выше, потому что как раз в ней часто вызывается jquery с гугла.
А вот у меня назрел вопрос, есть ли реальная разница между Asset::getInstance()->addString(""); и $APPLICATION->ShowHeadStrings(); в скоросрти работы, и не отвалится ли $APPLICATION в одном из обновлений битрикса, в результате полного перехода на D7.
Наверное, никто не будет спорить, что форма оформления заказа это самый сложный элемент для кастомизации, так как если внешний облик формы не устраивает клиента, то попотеть придется. Как-то так:
Поэтому, я поделюсь кое-какими соображениями о самой сложной части кастомизации - о блоке свойств. И да, речь пойдет исключительно об одношаговом компоненте как самом ходовом и современном.
А я использую компонент по шагам bitrix:sale.order.full и в нем нет файла props.php зато есть функция PrintPropsForm Есть варианты как отсортировать свойства по группам?
Дмитрий, не смотря на то, что это многошаговый, св-ва и так по группам должны идти (а иначе как?). Возможно ошибка какая-то, рекомендую в Битрикс стукнуть.
Зачем заменять маркеры в буферизированном блоке на живые поля ввода, если потом просто ставить continue? Не претендую на истину последней инстанции. Мне просто хочется разобраться.
Не так давно я писал пост о том . Пришло время CSV, но там еще проще.
require_once ($_SERVER["DOCUMENT_ROOT"]."/bitrix/modules/main/classes/general/csv_data.php";);
$csvFile = new CCSVData('R', true);
$csvFile->LoadFile($_FILES['csv']['tmp_name']);
$csvFile->SetDelimiter(',');
while ($arRes = $csvFile->Fetch()) {
ec($arRes);
}
Собственно: - подключаем файл класса работы с CSV - создаем объект класса, указываем, что будет использоваться разделитель (R, есть еще фикс.поля F), и первая строка содержит заголовки (true); можно не указывать эти параметры и задать отдельными методами
- загружаем файл - ставим делиметер, где допустимые параметры: \t (табуляция), запятая, пробел, точка с запятой. - бежим как при обычной выборке из базы (напомню, Fetch возвращает НЕ обработанные данные, а GetNext безопасные).
Semenov Roman, да никто же не спорит Тут вопрос скорее не "почему не использовали именно эту фичу", а "зачем понадобилось писать прослойку, да еще и не очень удобную"
Столкнулся с довольно странным поведением (сначала думал) продукта, убил прилично времени. Так что, поделюсь этими граблями. Грабли относятся к БД с транзакциями (INNODB в MySQL, в частности).
Суть - пытаемся записать в Журнал сообщение при добавлении поста в форум. В данном виде все отлично работает. Но стоит нам откомментировать две нижние строчки, как ничего не добавляется - автоинкремент таблицы Журнала увеличивается, но лог не пишется. Это сейчас на простейшем обработчике 2 + 2 связываются легко, но стоило времени дойти до этого
В чем магия? Дело в том, что добавление постов в форум (а может и в блоги) окружено такой конструкцией в компонентах:
StartTransaction
AddMessage()
Commit OR RollBack
Для непосвященных, основная фишка транзаций - все-все что мы делаем после StartTransaction, упадет в базу только после Commit. Если же делается RollBack, то ничего не добавится. Вообще ничего.
И вот в эти грабли я и попал - в AddMessage генерировалась ошибка, а далее (в компоненте) делался RollBack. Соответственно, запись не ложилась в таблицу.
А можно ли закрывать транзакцию, если ее не открывать? У тебя получается $GLOBALS['DB']->RollBack(); дважды. Один ты закрыл, a другой, наверняка, еще где-то.
Артемий, все можно, только будет ли толк )) тоже самое можно сказать человеку закрыть два раза дверь не открывая, он команду получит, но ничего делать не будет, т.к. дверь уже закрыта =)
Большое спасибо, Антон, за пример! Как правильно заметил Андрей, в документации не указана переменная $arTemplateParameters - кучу времени убил, чтобы разобраться, почему дополнительные параметры не подтягиваются. Битриксу как всегда двойка в этой области.
Долганин Антон написал: под рукой. Вот требуется вам сохранять элемент со свойством, передавая просто название элемента списка, и не париться о том, есть ли такой вариант, или надо добавить н
Да это старо как битрикс! А вот как сделать если ты хочешь добавить в шаблон bitrix:catalog кроме стандартного набора еще один компонент и при этом использовать настройки комплексного компонента ($component), но не просто вынести эти настройки во вкладку "Дополнительно", а создать свою вкладку, по аналогии с существующими (настройки ТОПа или "С этим товаром покупают")??? Вот это как реализовать? Как добавить свою группу в параметрах шаблона?
Казалось бы, в добавлении списочного свойства к заказу нет ничего сложного. Вот только станций метро у Москвы почти 2 сотни. Руками забить это тот еще ад. Поэтому, прилагаю скрипт для автоматического создания такого свойства. [CUT] В самом верху скрипта вам надо установить начальные значения свойства:
$PERSON_TYPE_ID = 1;// ID типа плательщика
$CODE = 'F_METRO';//код свойства
$PROPS_GROUP_ID = 1;//ID группы свойств
$NAME = 'Станция метро';//название
И выполнить этот код, например, в PHP-консоли в инструментах вашего сайта (в этом случае первую строчку <?php надо удалить). Скрипт в UTF.
Ну вот и все:
UPD: 24.01.18 Апдейт файла. Старый не удаляется по техническим причинам, качайте файл большего размера.
в D7 обработчик не будет работать! "Старыми", описанными методами - все ровно пашет, кроме момента определения CHARSET в b_lang - у меня почему-то пусто, хотя настройки сайтов выставлены...
Да и видимо добавили таки возможность слать аттачи
CEvent::Send("EVENT_NAME", SITE_ID, $arEventFields, "Y", "", array($file_id));
// где $file_id - это ID файла из таблицы b_file, файлов может быть несколько
Жутко (коллеги, голосуем) этот модуль. Кстати, когда я пришел в компанию ХХХ неокрепшим юнцом, веб-формы были первым модулем. То есть, я даже не знал где что лежит в Битриксе, а меня кидают в этот модуль. Представляете мой ужас? Я ненавидел этот продукт, не понимал восторга в лице коллеги-пма. Ну и вообще, отчаялся изучить сие ремесло. Но прошли годы, любовь к продукту появилась, ненависть к модулю осталась Но это лирика.
Задача. Изменить один ответ результата веб-формы после каждого добавления и изменения результата менять поле (допустим, писать туда информацию о пользователе). Вроде просто. В тех же ИБ это решается SetPropertyValueCode (аналогия кстати очень близка, но только в самой идеи, технологии и API рядом не стояли).
Проблема 1. Нельзя выводить это поле в форме (например, hidden'ом), ибо могут подделать.
Проблема 2. Изменить можно только посредством после сохранения. Но у него проблема - он требует передачи всех ответов одного результата, что довольно неприятно. Ищем зацепку. Находим -
Второй параметр - По умолчанию - "false" (будет взят стандартный массив $_REQUEST).
Так как в моем случае сохранение всегда происходило из формы, а не через API, то этот массив всегда полон и актуален. Решение оказалось простое:
То есть - подменяем ключ в реквесте, как-будто он прилетел от пользователя. И готово. Кстати, имхо как-то слишком тут не секюрно все это - что прилетело, то и кормим, не зависимо от того, были поля в форме или нет. Не зря не любил модуль.
Вот и все, задача решена. Приведу код обработчиков:
public static $disableUpdate = false;
public static function onAfterResultAddHandler($WEB_FORM_ID, $RESULT_ID) {
if ($WEB_FORM_ID==self::wfEvent2012reg && !defined('ADMIN_SECTION')) {
self::$disableUpdate = true;
$_REQUEST['form_dropdown_GUEST_STATUS'] = 72;
CFormResult::Update($RESULT_ID, false, 'N', 'N');
}
}
public static function onAfterResultUpdateHandler($WEB_FORM_ID, $RESULT_ID) {
if (!self::$disableUpdate && !defined('ADMIN_SECTION')) {
self::$disableUpdate = true;
$_REQUEST['form_dropdown_GUEST_STATUS'] = 72;
CFormResult::Update($RESULT_ID, false, 'N', 'N');
}
}
self::$disableUpdate нужен, чтобы скрипт не ушел в бесконечный цикл (обработчик вызывается внутри апдейта, где снова вызывается обработчик. Ну а ADMIN_SECTION требуется, чтобы в админке это поле можно было бы изменить.
Антон, обратите внимание, в формах есть вопросы, а есть еще поля!
"Вопрос" - это то что приходит из результата формы, а "поле" это как бы еще вопросы, но которые пользователь не редактирует и не видит.
В своем проекте, я записывваю в служебное поле статус пользователя на сайте, чтобы редактору сайта было проще понимать какой пользователь к нему обратился.
// для форм события с маленькой буквы!
// onAfterResultAdd
AddEventHandler( 'form', 'onAfterResultAdd', Array( "MyClass", "onAfterResultAddHandler" ) );
class MyClass
{
function onAfterResultAddHandler( $WEB_FORM_ID, $RESULT_ID )
{
if ($WEB_FORM_ID == 1 && $RESULT_ID > 0)
{
// подставим текущий статус пользователя.
global $USER;
$arLastStatus = CStatus::GetLastUserStatus( $USER->GetID() );
if ( is_array($arLastStatus) && isset( $arLastStatus["~NAME"] ) )
{
CFormResult::SetField($RESULT_ID, "STATUS", $arLastStatus["~NAME"]);
}
}
}
}
Иногда требуется ограничить количество использования многоразового купона. Возможно, когда-это это будет реализовано в продукте, но это сопряжено с множеством частных вариаций - кому-то факт применения купона требуется считать при оформлении, кому-то при оплате, кому-то при переводе в статус. Я накидал обработчик на завершение одношагового оформления заказа, кому надо - приспособит под себя.
Мини-дополнение. Если вы не хотите привязываться к ID, можно сделать хитрый финт с заголовком - в название скидки добавить какую-то метку, например, "Тестовая скидка (limited)". Тогда блок на 11-й строчке надо будет заменить на
if (preg_match('/\(limited\)$/is', $arCart['DISCOUNT_NAME'])) {
$arCoupons[] = $arCart['DISCOUNT_COUPON'];
}
На текущий момент, если на товар подействовала цепочка скидок торгового каталога, такой обработчик правильно будет работать только в том случае, когда купонная скидка была первой. Хранение информаци о всех подействоваших скидках в работе.
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
;
Тут вопрос скорее не "почему не использовали именно эту фичу", а "зачем понадобилось писать прослойку, да еще и не очень удобную"
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».
В 90% случаев подключаете первую jquery и подобные библиотеки и патом всё остальное и никаких проблем не будет, а если всё же есть то вы изобрели велосипед.
А вот у меня назрел вопрос, есть ли реальная разница между Asset::getInstance()->addString(""); и $APPLICATION->ShowHeadStrings(); в скоросрти работы, и не отвалится ли $APPLICATION в одном из обновлений битрикса, в результате полного перехода на D7.