Наверное, никто не будет спорить, что форма оформления заказа это самый сложный элемент для кастомизации, так как если внешний облик формы не устраивает клиента, то попотеть придется. Как-то так:
Поэтому, я поделюсь кое-какими соображениями о самой сложной части кастомизации - о блоке свойств. И да, речь пойдет исключительно об одношаговом компоненте как самом ходовом и современном.
А я использую компонент по шагам 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 Апдейт файла. Старый не удаляется по техническим причинам, качайте файл большего размера.
Дело в том, что именно первая строчка выплевывает jquery системный, а вторая строчка js-скрипты шаблона (которые по правильному должны подрубаться через AddHeadScript). Таким образом, если их поменять местами, сначала пойдут скрипты, использующие jquery, а затем сама jquery. Конечно же, jquery это лишь пример подводного камня.
PS: Такой же порядок в
<?$APPLICATION->ShowHead();?>
но мне метод не нравится в силу того, что я не могу сам раскидать теги как мне надо.
Не путайте людей, сейчас через настройки можно выносить все js вниз страницы, а их порядок зависит от порядка их регистрации в шаблоне.
В 90% случаев подключаете первую jquery и подобные библиотеки и патом всё остальное и никаких проблем не будет, а если всё же есть то вы изобрели велосипед.
в 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С-Битрикс».
