Laravel Mail: обзор 10 основных методов

Дата публикации: 26.09.2017

laravel-mailХэллоу! 🙂

Те, кто подписан на обновления проекта, и следит за выходом статей в курсе, что в одной из прошлых публикаций мы на примере создания формы обратной связи рассмотрели реализацию популярной технологии AJAX в Laravel.

Далее последовал обзор способов отправки почты, доступных в Laravel, и прочие публикации, которые меня отвлекли от процесса создания нашего тестового сайта.

И вот наконец-то (самому не верится :-)) сегодня мы завершим создание формы обратной связи в Laravel, реализуя отправку email сообщения администратору сайта на стороне сервера при получении AJAX запроса.

На данный момент у нас вместо этого шага, напомню, стоит заглушка в виде вывода на экран параметров запроса, являющихся данными полей формы.

Поехали 🙂

Инструменты Laravel API для отправки почты

Как вы помните из публикации о способах отправки почты в Laravel, для рассылки писем через SMTP, с помощью стандартной функции PHP mail(), sendmail, записи результатов отправки в логи и т.д. фреймворк предоставляет различные драйвера.

После того, как вы определились и прописали его в файлах конфигурации, отправка email с помощью данного драйвера будет доступна вам через API Laravel, а точнее, методы фасада Mail и Mailable классы, которые появились сравнительно недавно.

Сегодня я решил воспользоваться фасадом Laravel Mail — основной и единственной конструкцией для указанных целей вплоть до версии фреймворка 5.3, пока не появились Mailable классы и не вытеснили его с пьедестала.

Самое обидное, что с тех пор в официальной документации Laravel, которая всячески расширяется и переписывается с появлением каждой новой версии движка, упоминание об отправке почты непосредственно через Laravel Mail исчезло напрочь. Осталось только упоминание о нём и его методах для взаимодействия с новшеством Laravel Mailable.

А жаль. Лично я считаю, что отправка почты с помощью методов самого фасада — это штука достаточно мощная, надёжная, а в отдельных ситуациях удобная и незаменимая.

Однако, пока что это — всего лишь моё субъективное мнение 🙂 А согласитесь вы с ним или нет — для этого и предназначена данная статья, в которой я постараюсь описать наиболее характерные особенности Laravel Mail, чтобы в конце каждый сделал выводы о его необходимости и дальнейшем использовании самостоятельно.

Для сравнения Laravel Mail и Laravel Mailable планируется отдельная публикация, посвящённая последнему, в конце которой мы сравним оба инструмента Laravel для отправки почты и выясним, в каких ситуациях лучше использовать одни, а в каких — другие.

Но это всё в будущем, а пока переходим к обзору возможностей Laravel Mail.

Перед тем, как мы начнём, хочу порекомендовать вам одну полезную ссылочку на описание API Laravel Mail для версии движка 5.5 — https://laravel.com/api/5.5/Illuminate/Mail/Mailer.html. Если вам нужна другая, то на данном ресурсе есть описание API всех классов Laravel, начиная с версии 4.2.

Возможности Laravel Mail

Как вы могли понять, данный фасад (или попросту, системный класс Laravel) служит для отправки почты в Laravel и содержит массу методов для осуществления основного предназначения различными способами.

О том, что такое Laravel фасады, я не буду сейчас сильно расписывать. Думаю, сделаю это в отдельной публикации. Единственное, что сейчас нужно запомнить, так это то, что facades предоставляют статический интерфейс для использования классов фреймворка, т.е. вызываются они следующим образом:

Facade::method($params);

Здесь Mail — это алиас системного класса Illuminate\Support\Facades\Mail::class. Т.е. для использования фасада в коде можно не прописывать весь класс целиком, а лишь указать его алиас (псевдоним) следующим способом:

use Mail;

Кстати, полный список алиасов фасадов вы можете найти в файле /config/app.php в секции ‘aliases’ вашего Laravel проекта.

Поговорим о существующих методах Laravel Mail и их возможностях более детально.

http://cccp-blog.com/wp-includes/images/banners/templatemonster/banner_content.jpg

Mail::send()

Это основной метод фасада, через который, в конечном итоге реализуются некоторые другие.

Служит для отправки email через указанный в настройках Laravel почтовый драйвер. Позволяет использовать Laravel blade шаблон для оформления письма.

В качестве входных параметров принимает следующие значения:

void send(string|array|MailableContract $view, array $data = [], Closure|string $callback = null)

Первым параметром является имя шаблона, используемого для оформления письма. Может быть, как видно, string, т.е. текстовой строкой в виде имени файла blade шаблона относительно директории /resources/views (без расширения blade.php), array (массив для варианта отдельного указания файла HTML и текстовой части письма, использовался раньше вместо метода plain) и в Laravel 5.5 ещё и объектом MailableContract.

Второй параметр — это массив данных, которые используются в шаблоне и передаются туда.

Ну, и третий параметр — это функция, в теле которой возможно указывать отправителя, получателя, прикреплять файлы и т.д. (если не хотите, чтобы использовались глобальные значения, прописанные в конфиге /config/mail.php).

Примером использования всех возможностей в Laravel Mail::send может служить следующая конструкция:

Mail::send('email_view', ['user' => $user], function ($message) use ($user) {
    $message->from('sender@gmail.com', 'Sender');
    $message->to($user->email, $user->name)->subject('Test message');
});

Как видно из этого примера, в callback-функции также можно использовать данные из массива, передаваемого в шаблон. Ну, а полный список параметров письма, изменяемых с помощью callback, выглядит так:

$message->from($address, $name = null);
$message->sender($address, $name = null);
$message->to($address, $name = null);
$message->cc($address, $name = null);
$message->bcc($address, $name = null);
$message->replyTo($address, $name = null);
$message->subject($subject);
$message->priority($level);
$message->attach($pathToFile, array $options = []);
$message->attachData($data, $name, array $options = []);
$message->getSwiftMessage();

Думаю, что большинство этих свойств вам знакомы. Пару слов о некоторых из них.

Свойство priority нужно для указания приоритета сообщению при использовании очередей для отправки писем в Laravel, чтобы указать фреймворку, какие сообщения нужно отправить раньше остальных, а какие позже. Используются значения от 1 до 5, по умолчанию 3.

По поводу attach и attachData стоит сказать, что оба используются для прикрепления файлов к письму. Разница состоит в том, что первый прикрепляет файл, путь к которому передаётся в качестве первого аргумента, а второй формирует файл и прикрепляет его из бинарного кода, передающегося первым параметром.

Это может быть удобно для прикрепления файлов, генерируемых на сервере, без записи их на диск. Вторым аргументом в attachData передаётся имя файла, которое будет отображаться в виде ссылки для скачивания его в письме.

Метод getSwiftMessage позволяет получить базовый объект Swift Message в случаях, когда он необходим для дальнейших преобразований письма.

Mail::raw()

Отличие данного метода от предыдущего состоит в том, что он служит для отправки исключительно простых текстовых сообщений, которые не нужно оформлять с помощью HTML разметки, описанной в Blade шаблоне.

В качестве параметров принимает следующие значения:

void raw(string $text, mixed $callback)

Как вы видите, первым параметром указывается текст сообщения в виде строки, а вторым — callback функция с аналогичным назначением и свойствами, как и в случае send().

Работает на базе send() и является, по сути, её вызовом со специфически указанными параметрами:

send(['raw' => $text], [], $callback)

Mail::plain()

http://cccp-blog.com/wp-includes/images/banners/partner_web_studio/banner_728x90.gif

Данный метод очень похож на два предыдущих и является чем-то средним между ними, т.е. он позволяет использовать шаблон письма при отправке email, как send(), и при этом весь текст, содержащийся в шаблоне (даже HTML-теги и CSS-свойства) будет отображён в строковом виде, т.е. без предварительной обработки.

Лучше всего разница между send() и plain() видна из этого примера:

laravel-mail-otlichie-ot-plain

В обоих случаях для отправки почты в Laravel использовался один и тот же шаблон письма, только в первом email было отправлено при помощи plain(), а во втором — send().

Параметры у него такие же, как и у Mail::send() за исключением того, что они не имеют такую обширную типизацию:

void plain(string $view, array $data, mixed $callback)

Работает также на базе send() и является её вызовом со специфически указанными параметрами:

send(['text' => $view], $data, $callback);

Mail::render()

Данный метод новый и появился совсем недавно — в Laravel 5.5. Он позволяет отображать шаблон email как обыкновенный blade view в браузере.

Имеет следующие параметры:

View render(string|array $view, array $data = [])

Первый — имя blade view относительно директории /resources/views, второй — массив данных, которые будут отображаться в шаблоне.

Для примера её использования я решил написать простенький примерчик, отображающий в браузере шаблон письма, который использовался при демонстрации работы send():

//Метод контроллера
public function render()
{
    $user = ['message' => 'Test message'];

    $test = \Mail::render('emails.default', ['user' => (object) $user]);
    return $test;
}

//Правило маршрутизации в web.php
Route::get('/rendermail', 'ContactController@render');

В итоге, при переходе на url laravel.portfolio/rendermail я увидел следующее:

laravel-mail-predprosmotr-email-shablona-v-brauzere

Для чего нужен данный метод — думаю, понятно всем: чтобы не отправлять каждый раз письмо, когда вносятся какие-то правки по вёрстке с целью её корректировки. Хотя, по правде говоря, сделать то же самое можно было и старым добрым View::make() или хэлпером view():

public function render()
{
    $user = ['message' => 'Test message'];

    $test = \Mail::render('emails.default', ['user' => (object) $user]);
    return $test;
}

Так что вопрос использования Mail::render() — это чисто дело вкуса. Ну, и ещё вопрос манеры написания кода. Я, например, знаю людей, которые целенаправленно не используют в Laravel коде хэлперы и всё делают через методы специализированных фасадов и наоборот.

Если это ваш случай, то Mail::render() вам пригодится 🙂

Mail::queue()

Данный метод также очень древний, как и send() (по крайней мере, в API Laravel 4.2 он описан) и позволяет отправлять сообщение в очереди. До версии Laravel 5.5 он принимал следующие параметры:

mixed queue(string|array $view, array $data = [], Closure|string $callback = null, string $queue = null)

Как видите, по списку параметров он очень похож на send() и plain() за исключением последнего, в качестве которого может быть передано имя существующей очереди. Если же оно не будет указано, то будет использоваться объект очереди, существующий по умолчанию.

В Laravel 5.5 решили отказаться от этой давно существовавшей модели, адаптировав queue() под появление Mailable классов. В итоге, список параметров сейчас выглядит следующим образом:

mixed queue(string|array|MailableContract $view, string $queue = null)

Т.е. сейчас параметра всего два: имя файла шаблона и очередь, в которую будет добавляться письмо для отправки. Самое интересное, что, хотя в документации указано, что $view может быть string|array|MailableContract, в коде самого метода мы видим следующее:

if (! $view instanceof MailableContract) {
    throw new InvalidArgumentException('Only mailables may be queued.');
}

Как видно, $view может быть только объектом MailableContract, во всех остальных случаях фреймворк сгенерирует исключение.

Mail::queueOn() и Mail::onQueue()

Два абсолютно одинаковых метода, предназначенных для добавления письма в существующую очередь.

Тело функции queueOn() состоит только лишь из вызова onQueue(), а его тело, в свою очередь — в виде вызова queue(). Гениально, не правда ли? 🙂

Судя по документации API Laravel, onQueue() появился в версии фреймворка 5.1, и с тех пор существуют обе эти версии.

Не знаю, зачем нужно было его добавлять: то ли разработчики ошибочно писали один вместо другого, то ли снова борцы за чистоту кода подключились, то ли ещё что-то, но, в итоге, на сегодняшний момент мы имеет три абсолютно одинаковых метода в функциональном плане.

За единственным небольшим исключением, что в queue() параметр с названием существующей очереди необязательным (null по умолчанию), а onQueue() и queueOn() без его указания не будут работать.

Принимают на вход следующие параметры:

mixed onQueue|queueOn(string $queue, string|array $view)

Mail::later()

Данный метод также связан с отправкой очередей сообщений и позволяет добавлять сообщение в очередь по таймауту, т.е. спустя некоторое время. Также претерпел изменения в Laravel 5.5.

В более ранних версиях имел следующий список входных параметров:

mixed later(int $delay, string|array $view, array $data = [], Closure|string $callback = null, string $queue = null)

Как видите, всё то же самое, что и было у queue(). За исключением первого параметра, указывающего время задержки добавления письма в очередь, который является обязательным.

В Laravel 5.5 они изменились аналогично queue():

mixed later(DateTimeInterface|DateInterval|int $delay, string|array|MailableContract $view, string $queue = null)

Таймаут теперь, как видите, может быть не только целым числом, но и объектом DateTimeInterface|DateInterval, а $view, кстати, тоже может быть теперь только MailableContract, хотя в документации по АПИшке Laravel значатся ещё и string|array.

Mail::laterOn()

Аналогичен queueOn() и позволяет устанавливать задержку на добавление письма в существующую очередь. До Laravel 5.5 принимал на вход следующие данные:

mixed laterOn(string $queue, int $delay, string|array $view, array $data, Closure|string $callback)

Теперь этот список выглядит так:

mixed laterOn(string $queue, DateTimeInterface|DateInterval|int $delay, string|array $view)

На этом обзор основных возможностей фасада Laravel Mail окончен. Остались ещё нерассмотренные public методы, которые могут быть вызваны глобально через фасад, но они нужны для получения и установки объекта Swift_Mailer, получения объекта View Factory, списка адресатов, которым не удалось отправить письмо и т.д.

Я считаю, что описывать их все — чрезмерно, т.к. они необходимы в очень редких случаях. Если хотите — могу написать о них подробнее, лишь сообщите об этом в комментариях 🙂

Напоследок хочу сказать, что, начиная c Laravel 5.4 фасад Mail поддерживает методы трейта Macroable, позволяющего создавать макросы, с помощью которых можно изменять классы в режиме runtime, не внося изменения в код самих классов.

Основным методом Macroable (полный адрес трейта — Illuminate\Support\Traits\Macroable) является macro(), принимающий следующие параметры:

static void macro(string $name, object|callable $macro)

Первый — имя макроса, по которому он потом будет вызываться, второй — объект или функция, выполняющаяся при вызове макроса.

Для демонстрации я написал простенький примерчик, который будет выводить на экран сообщение при вызове Laravel макроса:

//AppServiceProvider.php
public function boot()
{
    \Mail::macro('test', function($value){
        dd('Hello, ' . $value . '!');
    });
}

//Метод контроллера
public function send()
{
     \Mail::test('foo');
}

Результатом стало выведение на экран сообщения «Hello, foo!». Скрин из браузера приводить не буду, если хотите — продублируйте у себя и убедитесь 🙂

Как видите, благодаря Laravel macro я смог зарегистрировать метод фасада Mail, не изменяя его класс напрямую. Честно говоря, я не особо понимаю, где данная возможность может пригодиться.

На ум приходит только разработка Laravel пакетов, которые будут взаимодействовать с кодом движка без его непосредственных правок. Если знаете что-то ещё или у вас самих есть опыт использования Laravel макросов — убедительная просьба поделиться своими знаниями в комментариях со всеми.

И на этой ноте мы заканчиваем обзор возможностей Laravel Mail и переходим к практическому применению знаний — к долгожданной реализации отправки почты через форму обратной связи на нашем тестовом сайте.

Реализация отправки почты с помощью Laravel Mail

Итак, вкратце напомню, что у нас готово на данный момент.

Имеется страница сайта с формой обратной связи, которая доступна по url http://laravel.portfolio/contacts. При нажатии на кнопку «добавить» на форме у нас вызывается JavaScript функция, которая отправляет AJAX-запрос на сервер. При получении ответа результат выводится в консоль браузера.

Обработчик запроса на сервере имеет вид метода контроллера Ajax/ContactController, который на данный момент всего лишь выводит на экран список входных параметров, которыми являются значения полей HTML формы.

Вот вместо этой «заглушки» мы сегодня и сделаем реальную отправку писем с помощью Laravel Mail фасада, сделав нашу форму обратной связи полноценной.

Прежде всего — выберем один из способов отправки почты в Laravel. Я решил остановиться на использовании SMTP Google, т.к. у меня уже есть настроенный для этих целей почтовый аккаунт Gmail. Таким образом, настройки окружения в файле .env у меня будут следующие:

MAIL_DRIVER=smtp
MAIL_HOST=smtp.gmail.com
MAIL_PORT=587
MAIL_USERNAME=my_mail@gmail.com
MAIL_PASSWORD=my_password
MAIL_ENCRYPTION=tls
MAIL_ADMIN_EMAIL=laradmin@gmail.com

Идём в код контроллера Ajax/ContactController, который расположен в файле app/Http/Controllers/Ajax/ContactController.php, и убираем заглушку. Для отправки почты я решил воспользоваться самым распространённым методом — отправкой письма с HTML шаблоном, что легко сделать с помощью Mail::send.

Напомню, что если не хотите заморачиваться HTML-оформлением, то используйте обычные текстовые сообщения или их шаблоны с помощью методов raw() и plain() соответственно. Я же решил немного усложнить себе жизнь, стилизовав письмо под дизайн шаблона сайта 🙂

Итак, сперва я создам шаблон письма.

Для этого я сделал новый каталог внутри resources/views и разместил в нём новый Blade view под названием default.blade.view со следующим примитивным содержанием:

<html>
    <head></head>
    <body>
        <div style="display: table; width: 100%; text-align: center; height: 40px; background: #68A4C4; color: #fff; font-family: 'Open Sans', Arial, sans-serif; font-size: 14px; font-weight: bold;">
            <div style="display: table-cell; vertical-align: middle;">Новое сообщение от клиента {{ $sender->name }}!</div>
        </div>
        
        <div>
            <div style="width: 50%; padding: 40px 25%; text-align: center;">{!! $sender->message !!}</div>
        </div>
    
        <div style="display: table; width: 100%; text-align: center; height: 40px; background: #68A4C4; color: #fff; font-family: 'Open Sans', Arial, sans-serif; font-size: 14px; font-weight: bold;">
            <div style="display: table-cell; vertical-align: middle;">E-mail для связи: {{ $sender->email }}</div>
        </div>
    </body>
</html>

Если вы никогда не делали шаблоны писем, хочу сказать, что для корректного отображения HTML разметки письма почтовыми клиентами нужно задавать стили HTML атрибутами или использовать свойство style, как я сделал это в примере выше.

К сожалению, если подключать CSS свойства так, как положено, то разметка к элементам письма не применится.

Чтобы не отправлять по 200 писем, чтобы скорректировать вёрстку, воспользуемся средствами Laravel для предпросмотра писем в браузере, а именно, методом Mail::render(), о котором мы говорили выше.

Для просмотра шаблона письма в браузере я сделал правило Laravel маршрутизации, прописав действие при переходе по нему прямо в самом правиле:

Route::get('/rendermail', function(){
    return Mail::render('emails.default', [
        'sender' => (object)['name' => 'test', 'email' => 'test@gmail.com', 'message' => 'Test message', 'subject' => 'Test subject']
    ]);
});

Как вы могли заметить по коду Laravel шаблона письма, в нём используются данные отправителя, передаваемые с формы при формировании email.

Поскольку прописанное правило маршрутизации будет вызываться при вводе url в адресную строку браузера и параметры будет затруднительно передавать, то я решил заменить их готовым тестовым массивом.

В итоге, в браузере при переходе по url http://laravel.portfolio/rendermail я увидел следующее:

laravel-mail-predprosmotr-shablona-pisma-v-brauzere

Такой вот простенький шаблончик получился 🙂 Поскольку это шаблон письма, которое будет видеть только администратор сайта на своей почте, то его внешний вид не критичен.

Если же вы захотите на своём Laravel проекте реализовать email рассылку пользователям о своих товарах и услугах, то нужно будет создавать что-то более презентабельное. Либо, если не хотите тратить своё время и силы, то можете приобрести готовые шаблоны писем, например, на TemplateMonster.

Итак, шаблон письма протестировали, теперь можно смело убирать правило Laravel routing из routes/web.php, где мы его прописывали, и переходить к реализации отправки самого письма.

Итак, заходим в контроллер Ajax/ContactController и модифицируем его код следующим образом:

<?php

namespace App\Http\Controllers\Ajax;

use Illuminate\Http\Request;
use App\Http\Controllers\Controller;
use Mail;

class ContactController extends Controller
{
    public function send(Request $request)
    {
        $result = false;
        
        if($request->ajax() && !empty($request->all()))
        {
            $sender = $request;
            
            Mail::send('emails.default', ['sender' => $sender], function($message) use ($sender) {
                $message->from($sender->email, $sender->name);
                $message->to(env('MAIL_ADMIN_EMAIL'));
                $message->subject($sender->subject);
            });
            
            $result = true;
        }
        
        return response()->json(['result' => $result]);
    }
}

Как видите, правкам подвергся единственный метод send(), который должен обрабатывать AJAX-запрос с клиента. Ну, и ещё добавил use Mail; в начало файла для использования фасада без бэкслеша перед его именем в коде.

В начале метода я прописал проверку на то, является ли полученный запрос AJAX и есть ли у него параметры.

Затем следует сама отправка email с помощью Laravel Mail. В качестве данных отправителя (email, имя), а также значения темы письма используются параметры запроса, которыми является информация, введённая пользователем в поля HTML формы.

Email получателя берётся из переменной окружения MAIL_ADMIN_EMAIL, которую я специально создавал в файле .env в одном из предыдущих уроков, так что если у вас её нет, то создайте вручную, указав ей в качестве значения email администратора для получения писем от клиентов. Либо, вместо её использования можете прописать адрес почты напрямую.

В итоге, если отправка письма удалась, то метод send() вернёт массив в формате JSON с одним-единственным элементом ‘result’, имеющим значение true. В противном случае будет false.

Теперь всё, что нам осталось для завершения реализации формы обратной связи в Laravel — это описать реакцию клиента при получении ответа от сервера. А будет она достаточно банальной: если сервер вернёт true, то покажем сообщение об успешной доставке письма, если false — сообщение об ошибке с просьбой связаться с администратором напрямую.

Блоки обоих писем уже содержатся в файле с HTML контактной формы в файле /resources/views/contacts.blade.php с id sendmessage и senderror. Если их у вас локально нет — просьба обновиться из Git репозитория проекта либо скопировать их оттуда локально.

Итак, для отображения соответствующих сообщений изменяем имеющийся код в public/js/app.js следующим образом:

$(document).ready(function(){
    $('#contactform').on('submit', function(e){
        e.preventDefault();
        
        $.ajax({
            type: 'POST',
            url: '/sendmail',
            data: $('#contactform').serialize(),
            success: function(data){
                if(data.result)
                {
                    $('#senderror').hide();
                    $('#sendmessage').show();
                }
                else
                {
                    $('#senderror').show();
                    $('#sendmessage').hide();
                }
            },
            error: function(){
                $('#senderror').show();
                $('#sendmessage').hide();
            }
        });
    });
});

Как видите, по сравнению с имеющимся кодом я убрал вывод в браузерную консоль результатов ответа от сервера в блоке ‘success’ и вставил код для отображения и скрытия соответствующих сообщений.
Также я добавил обработчик ошибок отправки запроса к серверу, который будет отображать сообщение о неудачной отправке письма.

Ну что? Всё готово и настало время для финальных тестов.

Заходим на страницу с формой обратной связи http://laravel.portfolio/contacts (url локальный для моего веб-сервера, поэтому пропишите его с учётом вашего локального доменного имени) и вводим следующие тестовые данные:

laravel-mail-testovye-dannye-formy

Нажимаем на кнопку «Отправить» и видим, что всё прошло успешно, о чём свидетельствует соответствующее сообщение:

laravel-mail-soobschenie-ob-uspeshnoj-otpravke-pochty

В результате мне на почтовый ящик, указанный в MAIL_ADMIN_EMAIL, пришло следующее письмо:

laravel-mail-itogovoe-pismo-s-shablonom-v-pochtovom-yaschike

Успех 🙂 Задуманное реализовано. Единственное, что меня насторожило при отправке письма — это то, что письмо отправлялось достаточно долго, но, учитывая, что я использовал SMTP, ещё и бесплатный, — данное поведение является допустимой нормой, в которое не нужно вмешиваться.

На этом у меня всё 🙂 Если возникли какие-то вопросы и сложности по поводу реализации отправки письма с помощью Laravel Mail — пишите о них в комментариях, постараюсь всем помочь. Напоминаю, что код, разработанный в рамках сегодняшнего урока, содержится в репозитории проекта на GitHub, ссылку на который можно найти в статье.

Также не ленитесь писать свои отзывы о статье в целом — это помогает мне делать более качественный материал, который будет полезен и интересен большинству.

Если сегодняшняя статья вам понравилась и вы хотите сказать мне «спасибо» — делайте её репосты в социальные сети и ставьте оценки звёздочками под ней.

Всем удачи и до новых встреч!

Понравилась статья? Поделись с друзьями:
  1. 5
  2. 4
  3. 3
  4. 2
  5. 1
6 голосов, в среднем: 4.3 из 5

Похожие темы

7 комментариев к статье "Laravel Mail: обзор 10 основных методов"

  1. Дмитрий

    Приветствую.
    Делал форму по вашим урокам. На локалке с Опен сервером всё работало, почта отправлялась. Правда отправлял не на Гугл, а на mailtrap.io. Перенес сайт на хостинг, но ни как не пойму почему не работает отправка писем с сайта: Address in mailbox given [] does not comply with RFC 2822, 3.6.2. Подскажите, если есть возможность.

    1. Pashaster Автор

      Добрый день! Если настройки отправки почты, которые работали на локалке, после переноса на хостинг не менялись, то причина одна — хостинг провайдер. Обратитесь в техподдержку, думаю, они помогут решить Ваш вопрос.

  2. Рустем

    Осилил таки все статьи, способ изложения напомнил некоторых злобных преподов с универа), но доходчиво и понятно). Вы могли бы развить данную тему еще больше?, например порезать на блейды view_ху » ../blog» и подключить crud, с пагинацией и прочими плюшками, или это излишне тривиально и скучно?

    1. Pashaster Автор

      День добрый 🙂 Развивать эту тему я планирую, т.к. Laravel мне самому безумно нравится, но времени пока очень мало.

  3. Andrey

    Mailables это просто следование хорошей практике написания кода приложения. Вся логика настройки и отправки email вынесена из контроллера в отдельный класс. Я думаю что продвинутые в ООП программировании так и делали еще до появления mailables, как, впрочем, и во всех других контроллерах, а не только в случае отправки email. Так что я бы рекомендовал использовать Mailables и посмотреть на другие контроллеры , особенно resource и вынести логику (store, update, delete скорее всего точно имеют довольно много кода для реализации логики) в отдельные классы.

    1. Pashaster Автор

      Добрый вечер! Спасибо за комментарий 🙂

      По поводу Mailables — я уже в какой-то статье намекал на ту фишку, которую Вы описали. Я лично вижу смысл их использовать, чтобы избежать дублирования кода. Когда в разных местах приложения будет оправляться email одинаковым образом — логично, что такой код нужно выносить в отдельный класс. В моём конкретном примере на данный момент отправка почты будет только с формы обратной связи, поэтому я решил не заморачиваться особенно с Mailable — классами. В будущем, если функционал разрастётся, думаю, что переключусь на данные структуры.

      По поводу отдельных классов для CRUD-функций, тут вопрос двоякий. С одной стороны, если логика в этих действиях будет одинаковой — да, смысл выносить её в отдельные классы определённо есть. Но вот если из общего у них будет только название, то будут наблюдаться серьёзные проблемы при кастомизации методов родительского класса. А если их переопределять, то смысла в вынесении в класс не будет.

      В любом случае, спасибо Вам за идеи для рефакторинга.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *