UPD все основные скандалы-интриги-расследования - в этом посте данной ветки
===================
Добрый день!
Суть проблемы в следующем - сегодня с утра внезапно перестало уходить письмо пользователям с подтверждением регистрации. В шаблон почтового события не лазил, в тип события тоже. Вчера только меня другое почтовое событие, но еще вчера вечером все было отлично. Грубо говоря рабочий день кончился в 18, в 23 еще пользователи регились нормально, сегодня с утра - уже не уходят письма.
Нашел отправку в компоненте bitrix:main.register, выглядит вот так:
Попробуйте посмотреть, что лежит в таблице b_event. Например, sql-запросом SELECT * FROM b_event ORDER BY ID DESC Он вам выдаст все события в обратном хронологическом порядке, смотрите события с названием NEW_USER_CONFIRM. Что стоит в поле 'SUCCESS_EXEC'?
Самое удивительное что этот запрос вообще не показывает событий "NEW_USER_CONFIRM" за последние 2-3 дня. Хотя я знаю что вчера пользователи регистрировались, статус у них "Активен" - значит письмо им приходило и почту они подтверждали =\
Я могу для теста посоветовать временно сменить $event->SendImmediate на $event->Send, попробовать зарегистрироваться и посмотреть опять же таблицу b_event. Там обычно маркировка отправки стоит.
d4rkolian пишет: Думаю может быть сделать проверку\оптимизацию и восстановление таблиц в БД? Может поможет.
Панацеей не стало, к сожалению. После проверки\восстановления таблиц попробовал снова - письмо не пришло, в b_event записи о письме не появилось. Хотя другие записи (оформление, изменение статуса заказа) появляются там постоянно и все ок.
На данный момент пока отключил подтверждение e-mail адресов, но это, конечно, временное решение. Хотелось бы докопаться до истины.
Я думаю, тут одно из двух: Или Вы в неправильном месте поменяли добавление события (то есть код не запускается) Или у Вас не работает инсерт в таблицу по какой-то причине.
В первом случае надо попробовать, допустим, перед и после добавления события класть в файл/лог что-нибудь. Во втором - попробуйте вручную сделать инсерт с данным событием. Допустим, из корня с помощью функции. Можно попробовать через CEvent::Send, восстановив все соответствующие поля, можно через $DB->Add("b_event", $arLocalFields, Array("C_FIELDS"));
Так. Теперь все стало еще в тысячу раз интересней. Я надеюсь еще кто-то читаю эту ветку.
Во-первых, хотелось бы узнать, знает ли кто-нибудь что за событие "VIRUS_DETECTED" Битрикса и по какому поводу оно пишется в b_event?
Теперь к сути. Неделю назад (17.06.2011), на сайте резко скакнул вверх траффик рано утром. Вместо 30-40 одновременных пользователей на сайте находило ~270, причем модуль битрикса говорил что по IP-адресам это преимущественно Дания, Ирландия, Греция и прочая Европа. Яндекс.Метрика показывала в источниках переходов 90% - "прямые заходы". Для сравнения - в обычные дни зарубежный траффик составляет <1%, а прямые заходы - до 17-20% в лучшем случае. Стало ясно что что-то никак. Обратились к хостеру (не буду называть его имя, чтобы не сочли за рекламу). Хостер предложил просто обрубить весь зарубежный траффик на 7 дней. Так как решение надо было принимать срочно - так и сделали.
А теперь о том почему я пишу это в этом топике. Потому что сегодня в 11 утра прошло ровно 7 суток как траффик был перекрыт, его автоматически разблокировали - и все продолжилось. Более того, письма которые не приходили - сразу же пришли.
P.S. когда начинал писать эту простыню, думал что VIRUS_DETECTED имеет к этому отношение, но сейчас посмотрел - такие записи появляются в b_event стабильно долго (уже больше года точно, а это практически все время работы системы)
Если кто-нибудь сможет помочь - было бы очень здорово.
VIRUS_DETECTED это стандартное событие битрикса на обнаруженный вирус. /bitrix/admin/type_edit.php?EVENT_NAME=VIRUS_DETECTED Там в шаблоне письма есть примерные инструкции, что делать по этому событию. Что говорит проактивная защита?
/bitrix/admin/event_log.php?lang=ru&set_filter=Y&find_type=audit_type_id&find_audit_type[]=SECURITY_VIRUS примерно так можно увидеть все, из-за чего было записано данное событие.
Суть проблемы в следующем - сегодня с утра внезапно перестало уходить письмо пользователям с подтверждением регистрации.
Такая же ерунда блин. Чем ситуация закончилась? или еще не закончилась?
У меня отправляет это письмо, только если неавторизованный пользователь начинает оформлять заказ и прямо при заказе регистрируется. Во всех остальных регистрациях не отправляется письмо.
столкнулся с проблемами при регистрации с подтверждением через e-mail. ситуация следующая:
1С-Битрикс: Управление сайтом 11.0.4
17 поддоменов на экземпляре битрикса.
При регистрации нового пользователя, сообщение отправляется только на один из поддоменов указанный в типе почтового сообщения NEW_USER_CONFIRM, причем на тот, который указан был последним !!! это навело меня на мысль.... что где-то непоправили работу с б.д. стал разбираться с таблицами: b_event_message и b_event_message_site разобрался и в итоге написал свой скрипт (за основу взял не помню чей), исправив кое что под себя и собственно SQL запрос:
старый был:
Код
global $DB;$event = $DB->ForSQL( $event );$lid = $DB->ForSQL( $lid );$rsMessTpl = $DB->Query( "SEL ECT * FR OM b_event_message WHERE EVENT_NAME='$event' AND LID='$lid';" );
новый запрос учитывает, что на одном экземпляре битрикса может быть много поддоменов:
Код
global $DB;$arr_result = array();$arr_items = array();$event = $DB->ForSQL( $event );$lid = $DB->ForSQL( $lid );$str_sel = "SELECT e.id, e.active, e.email_from, e.email_to, e.subject, e.message, e.body_type,";$str_sel .= "e.bcc, e.reply_to, e.cc, e.in_reply_to, e.priority, e.field1_name, e.field1_value,";$str_sel .= "e.field2_name, e.field2_value, s.site_id as lid";$str_sel .= " FR OM b_event_message e, b_event_message_site s";$str_sel .= " wh ere s.event_message_id = e.id and e.event_name='$event' and s.site_id='$lid';";$rsMessTpl = $DB->Query( $str_sel );
посредством этих изменений получил исправную отправку емэйлов с подтверждериями (и не только этих емэйлов!!!) если кому-то будет интересно могу этот скриптик сюда кинуть. я так понимаю - проблема эта возникает только у использующих нескольких поддоменов
Александр Мушников пишет: если кому-то будет интересно могу этот скриптик сюда кинуть. я так понимаю - проблема эта возникает только у использующих нескольких поддоменов
Здравствуйте, Александр. Был бы очень признателен, если поделились бы скриптиком и кратким описанием, что и как поменять, чтобы заработало всё .
Александр Мушников пишет: если кому-то будет интересно могу этот скриптик сюда кинуть. я так понимаю - проблема эта возникает только у использующих нескольких поддоменов
Здравствуйте, Александр. Был бы очень признателен, если поделились бы скриптиком и кратким описанием, что и как поменять, чтобы заработало всё .
Здравствуйте. в архиве 2 файла: скрипт для отправки e-mail подтверждения и init.php (в коем стоит его вызов) архив можно скачать по ссылке: bitrix-alternative_user_mail_confirm.rar
особых инструкций нет. скрипты должны находится в тех-же папках на сервере, в которых они находятся в архиве. если у вас уже есть в папке: /bitrix/php_interface/ скрипт: init.php то тогда из init.php (который в архиве) все что находится между тегами PHP необходимо скопировать в ваш init.php. для того что-бы все работало - необходимо, что-бы для нужного сайта имелся активный почтовый шаблон для типа события NEW_USER_CONFIRM, и в шаблоне должны использоваться следующие поля:
если у вас в почтовом шаблоне используются некоторые другие названия полей, и вы не хотите их менять, то тогда измените эти поля в скрипте, в фунции отправки: Send_Mail_Only_Fixed( $event, $lid, $arFields, $mail_to, $debugging ) еще сделана возможность насильно указать при вызове e-mail адресата в параметре $mail_to, если он не пустой, то используется он. так например в init.php вызывается эта функция: Send_Mail_Only_Fixed( "NEW_USER_CONFIRM", SITE_ID, $arFields, $arFields[ "EMAIL" ], "RETURN_DEBUG_INFO" ); последний параметр - любая непустая строка ( "RETURN_DEBUG_INFO" ) приводит к возврату массива с отладочной информацией. если все работает правильно и отладка не нужна - его указывать не нужно.
P.S. перед тем как использовать альтернативную отправку - проверьте, может быть у вас и так все работает, а отправленные письма с подтверждениями успешно ложаться в "СПАМ" у вас или у вашего почтового провайдера. в этом случае нужно изменить всего-лишь настройки вашего СПАМ - фильтра в вашем почтовом ящике.
Александр Мушников пишет: При регистрации нового пользователя, сообщение отправляется только на один из поддоменов указанный в типе почтового сообщения NEW_USER_CONFIRM, причем на тот, который указан был последним !!! это навело меня на мысль.... что где-то непоправили работу с б.д. стал разбираться с таблицами
Было здорово, если бы Вы обратили внимание битрикса на это. Глядишь и исправили бы когда-нибудь...
Было здорово, если бы Вы обратили внимание битрикса на это. Глядишь и исправили бы когда-нибудь...
Я думаю, они это уже исправили, а у пользователей, у которых не срабатывает отправка, скорее всего на самом деле все работает, но письма попадают в спам. или что-то еще с настройками - причин может быть масса... У меня ситуация вообще загадочная. Пока все отлаживалось на тестовм экземпляре битрикса, шататная отправка уведомлений не работала, и я сделал выше описанным образом. Но когда внедрил это все на рабочем экземпляре битрикса, то пользователи стали получать уведомления в двух экземплярах - одно отправленное штатными средствами битрикс, а второе через init.php. так что в init.php пришлось закомментарить вызов отправки.
Попробуйте проверить какая почта указана в настройках сайта в поле E-Mail адрес по умолчанию. В почтовом шаблоне NEW_USER_CONFIRM используется макрос #DEFAULT_EMAIL_FROM# в поле От кого. В моем случае письма не хотели уходит с почтой указанной в настройках, после изменения почты на другую в настройках все заработало.
Разработка интернет магазина под ключ на 1С-Битрикс www.electroid.org, интеграция битрикс и 1С.