В эпоху роста удобств веба я всячески лоббирую свободу пользователей интернет. Табу на капчи, табу на регистрации. И пока я делаю сайты (кстати, решил завязать), я буду это и дальше лоббировать. Представляю вашему вниманию способ как можно избавить посетителей от нудятины в виде регистрации при оформлении заказа.
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 юзера передавать с 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С-Битрикс».