В эпоху роста удобств веба я всячески лоббирую свободу пользователей интернет. Табу на капчи, табу на регистрации. И пока я делаю сайты (кстати, решил завязать), я буду это и дальше лоббировать. Представляю вашему вниманию способ как можно избавить посетителей от нудятины в виде регистрации при оформлении заказа.
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: Как уже писал выше, это выкладки с компонента, который я прилично переправил, возможно что-то упустил при написании данного поста. Указывайте, пожалуйста неточности в комментариях или вопросы.
Важные замечания и ответы на кое-какие вопросы читайте в комментариях.
1. Проверьте, доходит ли исполнение вообще до строчки $userID = $obUser->Add($arFields); Естественно попробуйте под гостем с мылом, которого еще нет в базе.
2. Добавьте сразу после вышеуказанной строки этот код:
echo "Error: ".$obUser->LAST_ERROR."!";
die();
И попробуйте оформить заказ. Может где-то тут собака порылась..
Сразу же поставьте еще одну ловушку перед CSale::Add: echo $userID."!"; die();
Если первая не сработает, то хоть будет что в итоге пытается подсунуть Битрикс в заказ.
При echo $userID."!"; die(); и echo "Error: ".$obUser->LAST_ERROR."!"; die(); ничего не оформляет и показывает ! при echo "Error: ".$obUser->LAST_ERROR."!"; die(); без echo $userID."!"; die(); пользователя не добавляет и оформляет заказ на администратора и входит в систему под его логином
Маленькое дополнение: входит под логином администратора потому, что другого пользователя нет. Если пользователи еще есть, то оформляет на последнего зарегистрирванного и автоматически входит под его логином
Если так напрямую воткнуть 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 и ФИО из свойств, но это: - лишнее время займет - увеличит количество запросов
Группы на сайте создаются не только сотрудниками «1С-Битрикс», но и партнерами компании. Поэтому мнения участников групп могут не совпадать с позицией компании «1С-Битрикс».