Сработал совет Евгения Смолина написать в поддержку TimeWeb,
Они подсказали другие настройки крона. Через http-запрос. (wget . Так заработало.
Они подсказали другие настройки крона. Через http-запрос. (wget . Так заработало.
|
>> не проще заплатить тысячу рублей любому спецу и найдут причину?
А программист с 20-летним стажем - я сейчас про себя - это не спец? Работу, стоящую 1000 руб., сама сделать не могу? Участники темы здесь написали много версий. Ни одна не помогла. Что еще может сделать спец, сверх написанного здесь? Евгению Смолину спасибо! И всем неравнодушным, участвовашим в обсуждении - тоже! |
|
|
|
|
|
У меня не заработало и после внесения всех отличий со скриптом Евгения Смолина.
Поэтому два вопроса к Евгению. 1. Вы привели вырезку из реально работающего скрипта на кроне? Или это тоже тестовый скрипт. Тогда чем подтверждено, что после
выполнение скрипта продолжается? Что-то как-то логируется в теле страницы? У меня ведь тоже ошибок нет, все просто останавливается на вышеприведенном операторе. 2. Какая команда на кроне запускает ваш скрипт? |
|||
|
|
|
|
Пока все мимо кассы.
Сама переменная $_SERVER['dOCUMENT_ROOT'] пуста, проверяла логированием. Именно поэтому я ее и задаю. Всегда так делала, ставя битриксовые задачи на крон. Впервые такое пролет. #!/usr/bin/php в начало скрипта я ставить не стала. Так как команда на кроне выглядит так:
Все нужное есть для выполнения скрипта.
Почему из-за нее умирает скрипт? |
|||||||||||||
|
|
|
|
Увы! Дело не в письме.
После включения
Отправку письма можно заменить логированием или каким-то другим кодом - , не работает ничего, все останавливается на этом require. |
|||
|
|
|
|
Не работает скрипт на кроне в TimeWeb. Самый простой, тестовый.
Сам скрипт поставлен на крон в панели управления TimeWeb, не через cron_events.php Вот так все работает нормально и почта приходит
Убираю комменты с предпоследней строки, почта перестает приходить. Замена почты логированием в файл дает аналогичный результат. При запуске из браузера скрипт работает нормально. Переменная $_SERVER["DOCUMENT_ROOT"] задана правильно. Логи ошибок пусты. Кто-нибудь что-то может подсказать? |
|||
|
|
|
|
Совет удалять такие аккаунты на событии добавления пользователя не подходит. Не могу придумать алгоритм отличия регистрации бота от ренистрации человека.
Боты отличаются от нормальных аккаунтов только идиотскими именами и емейлами. А так все поля заполнены, все группы проставляются правильно. |
|
|
|
|
|
Добрый день.
А кто-то, попавший под эту раздачу, встречался с постоянной регистрацией ботов как пользователей сайта? Какие-то рецепты противодействия есть? На моем сайте каждые 5 минут регистрация нового аккаунта. А потом обращение к /bitrix/redirect.php Redirect.php закрыла через .htaccess. Но регистрация новых пользователей продолжается. И список пользователей забивается, и таблица b_users раздувается, замедляются выборки по ней. Оно мне не надо. |
|
|
|
|
|
Опытный и ответственный 1С-Битрикс-программист ищет постоянную подработку. Опыт программирования под 1С-Битрикс - 16 лет.
В идеале - небольшой интернет-магазин, нуждающийся в постоянном присмотре. 1100 руб/час, возможен Договор с ИП (+7%). Мне интересна также наработка скиллов по программированию в Vue.js и под Битрикс24. Такие задачи - 600 руб/час. Мой трудовой путь - здесь - Отзывы бывших заказчиков - здесь - Пишите, пожалуйста, в личку или rudninaСОБАКАyandex.ru |
|
|
|
|
|
Если это еще актуально.
100% точности не гарантирую. Так что прошу тапками не кидать. В списке событий модуля Sale, генерируемом bitrix.liveapi, я просто не увидела ничего относящегося к смене статусов. Смотрим дальше. За отправку почтовых сообщений отвечает класс \Bitrix\Sale\Notify Смотрим код соответствующего файла /bitrix/modules/sale/lib/notify.php И видим, что метод sendOrderStatusChange содержит только обработку старых событий. В том числе и устаревшего OnOrderStatusSendEmail Таким образом, я делаю вывод, что менять поля сообщений или добавлять новые нужно пока именно на этом устаревшем событии OnOrderStatusSendEmail. Хорошее описание его использования дано здесь - |
|
|
|
|