В эпоху роста удобств веба я всячески лоббирую свободу пользователей интернет. Табу на капчи, табу на регистрации. И пока я делаю сайты (кстати, решил завязать), я буду это и дальше лоббировать. Представляю вашему вниманию способ как можно избавить посетителей от нудятины в виде регистрации при оформлении заказа.
UPD: небольшие изменения в коде, закрывающие брешь в безопасности. Спасибо за замечание Сергееву Ивану. Изменения помечены красным. [spoiler] Итак, для начала переносим компонент оформления заказа в свое пространство имен. Как это сделать - опущу. Я выбрал злободневное оформление заказа на одной странице sale.order.ajax из последней версии модуля.
Изменения будут только в component.php.
1. В самом верху (28-29 строчка) убираем этот код:
Ниже по тексту наполняется $arFields. Там меняем один параметр: "USER_ID" => $userID,
Внимание! Данный отрезок кода просто добавляет пользователя, но не отсылает ему письмо с регистрационными данными. Чтобы это происходило, надо воспользоваться CUser::Register заместо CUser::Add. Но проще после создания пользователя (строка $userID = $obUser->Add($arFields) дописать строку:
CUser::SendUserInfo($userID, SITE_ID, "Приветствуем Вас как нового пользователя нашего сайта!");
Тут особо отмечу моменты: $_POST["ORDER_PROP_$EMAIL_PROPS_ID"] - это e-mail, у вас обязательно должно быть такое свойство заказа. У меня ID этого свойства 3. Надеюсь все поняли о чем речь. $_POST["ORDER_PROP_$FNL_PROPS_ID"] - это ФИО. Тоже свойство заказа. Ведь нам надо гостя как-то обозвать. Тут подход индивидуальный. У меня одно свойство на ФИО. Если у вас несколько (отдельно под фамилию, отдельно под имя), то исправьте код:
В $arNames у нас должны оказаться фамилия, имя и, если хотите, отчество. Именно в таком порядке.
"GROUP_ID" => explode(",", COption::GetOptionString("main", "new_user_registration_def_group")), - хитрый финт, который пользователя помещает сразу в группы, которые указаны в настройках главного модуля. Сам когда-то допер
$userLogin = "client".time(); - это будущий логин клиента. будет что-то типа client123654987
Теперь нам необходимо обработать завершающий шаг. Весь component.php по сути разбит на два больших блока. if(IntVal($_REQUEST["ORDER_ID"]) <= 0) //тут подготавливаем оформление заказа, собираем данные с пользователя и } else { вот тут нам и надо изменения внести.
Теперь переходим в область ниже глобального else (см. выше), но прежде else меняем на elseif(check_bitrix_sessid()).
Там сразу идет выборка заказа с помощью $dbOrder = CSaleOrder::GetList. В фильтре метода меняем строчку
"USER_ID" => IntVal($USER->GetID()),
на
"USER_ID" => IntVal($_REQUEST["USER_ID"]),
Вот собственно и все.
Вкратце работает так. Смотрим, есть ли пользователь с таким мылом в базе. Если нет, то создаем. Выдергивается последний пользователь с указанным e-mail'ом.
Зачем нам его авторизовывать после добавления? Потому что его перекинет на страницу оплаты, где уже идет проверка на авторизацию и это надо. Если хотите, сами уже как-нибудь обработаете этот момент.
Особо удобно подход гостевого оформления заказа пользовать вкупе с ссылками автовхода.
PS: Как уже писал выше, это выкладки с компонента, который я прилично переправил, возможно что-то упустил при написании данного поста. Указывайте, пожалуйста неточности в комментариях или вопросы.
Важные замечания и ответы на кое-какие вопросы читайте в комментариях.
Маленькое дополнение: входит под логином администратора потому, что другого пользователя нет. Если пользователи еще есть, то оформляет на последнего зарегистрирванного и автоматически входит под его логином
Если так напрямую воткнуть ID, то все работает. Но возникает сразу несколько вопросов. Это только для физического лица, а если юридическое? Пользователю не отправляются ни сообщения о регистрации6 ни сообщения о принятом заказе с данными входа. Как он теперь узнает свой пароль для входа, чтобы входить в персональный раздел? В каждом случае пользоваться функционалом восстановления забытого пароля?
Андрей, я очень редко пишу статьи для конечного пользователя продукта. Просто потому что не умею
Все мои писанины как правило направлены на разработчика. Чтобы он мог что-то дописать по своему. В частности,
Пользователю не отправляются ни сообщения о регистрации6 ни сообщения о принятом заказе с данными входа.
конечно не отправится, потому что мы добавляем пользователя Add'ом.
Просто я не использовал отправку паролей по простой причине - зачем пользователя захламлять ящиком. Потом он входил автовходом. Выше в посте есть ссылка на то, как это сделать.
Вот что я добавил в посте:
Данный отрезок кода просто добавляет пользователя, но не отсылает ему письмо с регистрационными данными. Чтобы это происходило, надо воспользоваться CUser::Register заместо CUser::Add. Но проще после создания пользователя (строка $userID = $obUser->Add($arFields) дописать строку:
CUser::SendUserInfo($userID, SITE_ID, "Приветствуем Вас как нового пользователя нашего сайта!");
Но вроде это письмо не шлет пароль, а ссылку на его смену. В принципе в большинстве случаев подойдет. Как вариант, можно создать свой тип почтового события по аналогии USER_INFO, с паролем и другими данными пользователя и слать его, а SendUserInfo убрать (не писать).
Это только для физического лица, а если юридическое?
Имеете в виду как получить e-mail? Повторюсь, подход индивидуальный. Добавляйте свойство с e-mail'ом, вместо свойства "ФИО" будет "ФИО контактного лица компании" и все то же самое.
Если вы имеете в виду как узнавать какой тип плательщика, то в том отрезке кода будет доступна переменная $arUserResult["PERSON_TYPE_ID"], которая хранит ID типа плательщика.
И перед "/*Create user ------------------------*/ " я бы воткнул:
if ($arUserResult["PERSON_TYPE_ID"] == 1) // физическое лицо
{
$EMAIL_PROPS_ID = 1;
$FNL_PROPS_ID = 2;
}
else // юридическое лицо
{
$EMAIL_PROPS_ID = 2;
$FNL_PROPS_ID = 3;
}
То есть, если физик, то айдишники имени и фамилии одни, а если юрик, то другие.
Да, конечно можно было бы вообще универсально сделать и выдергивать e-mail и ФИО из свойств, но это: - лишнее время займет - увеличит количество запросов
Добрый день всем! Для меня эта тема с недавних пор стала довольно больным вопросом, с того момента, как руководство вынесло вердикт упростить процесс покупки и разрешить покупать абсолютно всем без регистрации. Выражаю огромный респект автору этого поста, очень помог !!!
Предлагаю вариант доработки этого фрагмента, который помогает избежать авторизации под админом и в тоже время будет авторизовывает тех юзеров, которые уже зарегистрированыы на сайте. Т.к. клиентская база у нас уже огромная (около 10000 юзеров в общей сложности) пришлось "изобретать велосипед" и привязываться на "мыло". А если учесть что я не так давно занимаюсь PHP и вообще программированием, то прошу "бить ногами" Итак, начноем! Этот код
if($_POST["ORDER_PROP_8"]){
$mail = $_POST["ORDER_PROP_8"]; //$_POST["ORDER_PROP_8"] - это свойство заказа с мылом, просто я по ID завязывал, а не по имени свойства
}else{
$mail = $_POST["ORDER_PROP_12"]; //$_POST["ORDER_PROP_12"] - а тут мне пришлось указать свойство для юр. лих, т.к. с физическими они разходятся и у меня на сайте 2 типа плательщиков...
};
$rsUsers = CUser::GetList(($by="id"), ($order="desc"), array("EMAIL" => "$mail"));
while($arUser = $rsUsers->Fetch()):
$arGroups = CUser::GetUserGroup($arUser["ID"]);
foreach($arGroups as $arGroup => $arGroupID){
if($arGroupID == 1) //проверяем принадлежность к грппе администраторов
{
break;
}else{
$arUserUser = $arUser["ID"];
break;
};
};
endwhile;
if ($arUserUser)
{
$userID = $arUserUser;
}
я сделал так чтоб если кто новый юзер заводился, то в качестве логина ему присваивать егоже мыло, если не нравится, потом сам может исправить Хотя еще руки не дошли, надо в
поставить выбор не только из этого свойства, а как с мылом чуть выше сделать разделение в зависимости от типа плательщика. и в конце мы всетаки авторизуем пользователя
т.к. на сайте у нас используется оплата через различные платежные системы, включая счет и квитанцию от сбербанка.
Правда хочу всех предупредить, что эти изменения еще не тестировались глобально!!! Пока тестировал только сам немного... Поэтому будьте осторожны! Буду очень рад услышать ваши отзывы и рекомендации
Ну тут минус - зная мейл пользователя, можно залогиниться под ним (ведь, если кто-то получит доступ к обычному пользователю, тоже не есть гуд)
Что до оплаты на следующем шаге - там можно переделать компонент подключения платежки (оставим на домашнее задание ) и проверять сессию, а ID юзера передавать с GET.
Ну и еще комментарий, если уж данный подход рассматривать - проверять не "не принадлежность к админам", а "принадлежность к обычным", что можно дернуть с помощью COption::GetOptionString("main", "new_user_registration_def_group"), это группы через запятую, в которые попадет пользователь после регистрации. Ведь есть же еще саппорт, менеджеры, редакторы.
Но, положа руку на сердце, в некоторых случаях такое подходит - когда не критично что кто-то может получить доступ. Плюс если заказов пару десятков в день (максимум) и их внимательно обрабатывают.
Антон, спасибо огромное за статью. Сделал все исправления в стандартном компоненте, работает заказ, только почему то пользователь не регестрируется и заказ оформляется на последнего зарегестрированного пользователя в базе. Не подскажете в чем может быть дело?
всё поправил и выдаёт такую ошибка помогите:| Parse error: syntax error, unexpected $end in /home/users1/i/ivgrad-shop/domains/ivgrad-shop.jino.ru/bitrix/components/bitrix/sale.order.ajax/component.php on line 1631
4 года спустя.... sale.order.ajax теперь поддерживает оформление заказа для не авторизованного пользователя. А вот sale.order.full всё так же придётся кастомизировать...
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».