Можно ли отправлять почту с использованием PHP, давая обратную связь с пользователем в режиме реального времени?
Недавно я написал небольшое приложение для интрасети нашей компании для отправки отформатированных писем клиентам. Интерфейс довольно чистый и требует только ввода номера задания, затем он строит и отправляет почту. Почта, будучи построенной, получает несколько вложений с другого сервера, и все автоматизировано. В библиотеке используется PHPMailer .
Есть ли способ, используя другие технологии, возможно, но все же используя PHP в качестве основного языка, чтобы показать прогресс отправленных писем? Я проверил надежную проверку ошибок, чтобы проверить, действительно ли отправлено письмо и т. Д., Но мне не хватает способа дать пользователям визуальную подсказку о фактическом доставке почты на сервер через индикатор выполнения и т. Д.
Возможно ли это использование PHP и что-то вроде Ajax? Как вы определяете ход почты в пути?
Я думаю, что лучший вариант здесь – это оценить время. Вы можете проверить, сколько времени нужно отправлять почтовым сообщениям 10 МБ, чтобы узнать скорость приема вашего SMTP-сервера. С помощью этой информации вы можете оценить время передачи любого электронного письма на основе его размера и дать вашему клиенту некоторое визуальное отвлечение на основе этого.
Я не знаком с PHPMailer, но вам, безусловно, нужна поддержка библиотеки, чтобы иметь возможность запросить его о статусе отправляемых писем.
Учитывая, что PHP не имеет потоков, я бы предложил иметь очередь базы данных для доставки и иметь внешний PHP-процесс, запускаемый с основного сайта (или через cron), который обрабатывает поставки сбоку, отмечая в базе данных текущий статус при каждой поставке: NOT_PROCESSED, IN_PROGRESS, ПОДКЛЮЧЕНИЕ, ПОДКЛЮЧЕНИЕ, SENDING_DATA, ACCEPTED, FAILURE_X. Вы можете запросить базу данных для статуса при каждой доставке через Ajax.
Если PHPMailer внутренне использует стандартную функцию PHP mail (), которая использует сервер SMTP-ретранслятора на вашем компьютере, у вас не может быть такой информации о статусе (который вы имели бы, если бы создали сами сокеты), вы можете иметь только три основных состояния NOT_PROCESSED, IN_PROGRESS, FAILURE_X.
(FAILURE_X действительно представляет много состояний, поскольку объясняет причину сбоя).
Окончательное рассмотрение использования mail () заключается в том, что статус, который вы сможете узнать, – это просто статус из локального SMTP-реле, которое всегда будет принимать очень быстро, и вы не сможете определить, действительно ли почта доставляемый на исходящий сервер (по крайней мере, без необходимости взаимодействовать с ним или читать mailq, что является неприятным делом).
ОТКАЗ ОТ ОТВЕТСТВЕННОСТИ
Учитывая, что даже в хорошем случае, когда вы знаете по-настоящему статус, вы не можете знать, было ли электронное письмо получено на другом конце, и сколько времени это займет, я не уверен, насколько полезной была такая конструкция. Конечно, было бы забавно программировать, но я сомневаюсь, что это было бы очень полезно, может быть, просто некоторые глазные конфеты со стандартными отклонениями электронной почты (электронные письма могут быть потеряны при транзите, если он не повторит попытку, уйти еще до повторной попытки) будет достаточно ,
Если процесс электронной почты может отправить назад информацию, тогда он сможет обновить индикатор выполнения или текст прогресса с сообщениями.
Это похоже на то, как WordPress обновляет / устанавливает работу. По завершении процесса отображается текст, в котором говорится каждый шаг: «Загрузка xxxx.xxx.xxx», «Деактивация плагина», «Установка плагина», «Попытка реактивации», «Реактивация выполнена успешно»: что-то похожее. клиентская сторона и отправитель сообщений на сервере: по мере выполнения сценария он отправляет обратно сообщения клиенту.
Как уже говорилось ранее, это может только реально дойти до вашего сервера. Вы можете указать, успешно ли почта покинула ваш сервер, но без какого-либо шага конформирования электронной почты, я думаю, что это насколько возможно.
Я предполагаю, что у нас есть шанс завершить его, но не может быть уверен, что это решение уже сделано кем-то :(.
Мои мысли:
поскольку я знаю, что вы можете работать с сокетом в неблокирующем режиме stream_set_blocking (), тогда вы можете попытаться использовать этот подход для отправки писем через этот неблокирующий сокет.