Wysyłanie emaili w Laravel

Możliwość wysłania emaila do klienta, czy też powiadomienia go o czymkolwiek w jakikolwiek inny sposób (sms, push notification, etc.) to nieodłączny element każdej większej aplikacji internetowej.

Oczywiście Laravel jest wyposażony w narzędzia ułatwiające konfigurację, tworzenie oraz zarządzanie emailami wysyłanymi do klientów. W konsekwencji sprowadza się to do utworzenia tzw. providerów (zewnętrznych lub wewnętrznych) do każdego z rodzajów powiadomień (dla maili w app->config/mail.php), które chcemy stosować w aplikacji, a następnie wybrania go przy okazji wysyłania samego powiadomienia.

Tworzenie emaila

W Laravelu od wersji 5.3 dla każdego rodzaju emaila, którego chcemy wysłać klientowi tworzymy dedykowaną mu klasę. Klasa ta musi rozszerzać Illuminate\Mail\Mailable. Taką klasę możemy stworzyć komendą artisan: php artisan remove:mail CustomerCreated. Jak wnioskujesz po nazwie, będzie to mail wysyłany w związku z utworzeniem/rejestracją nowego klienta w aplikacji. Po wykonaniu polecenia, klasa opisująca ten email znalazła się w folderze app/Mail i wygląda tak:

namespace App\Mail;

use Illuminate\Bus\Queueable;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Mail\Mailable;
use Illuminate\Queue\SerializesModels;

class CustomerCreated extends Mailable
{
    use Queueable, SerializesModels;

    /**
     * Create a new message instance.
     *
     * @return void
     */
    public function __construct()
    {
        //
    }

    /**
     * Build the message.
     *
     * @return $this
     */
    public function build()
    {
        return $this->view('view.name');
    }
}

Przeanalizujmy tę klasę. <code>use Queueable, SerializesModels</code> potrzebne są – odpowiednio – aby móc dodawać ten mail do kolejki (opcjonalnie) oraz aby poprawnie serializować dane przekazywane w konstruktorze tej klasy do dynamicznego skomponowania treści maila.

Kluczową rolę odgrywa tu metoda build(). To właśnie w niej definiujemy wszystkie stałe szczegóły naszego maila, takie jak treść, szablon, temat itp. Czyli wszystko, oprócz adresata.

Natomiast konstruktor przyjmuje dane, które mają zostać przekazane do treści maila (szablonu). W konstruktorze możemy też zdefiniować dodatkowe atrybuty, które także będą dostępne w szablonie maila.

Poniżej jeden ze sposobów, jak moglibyśmy dostosować tę klasę reprezentującą maila o dodaniu nowego klienta:

<pre>
class CustomerCreated extends Mailable
 {
     use Queueable, SerializesModels;
/**
 * Create a new message instance.
 *
 * @return void
 */
public $customer;

public function __construct($customer)
{
    $this->customer = $customer;
}

/**
 * Build the message.
 *
 * @return $this
 */
public function build()
{
    return $this->subject("Klient {$this->name} {$this->surname} został utworzony")
                ->view('view.name');
}
}
</pre>

Nastomiast, aby wysłać tak zdefiniowanego maila, używamy takiej, raczej zrozumiałej składni:

Mail::to($user)->send(new AssignmentCreated($customer));

Do metody to() możemy przesłać zarówno instancję klasy/modelu $user lub kolekcję takich instancji – w jednym i drugim przypadku Laravel wyszuka na bazie wartości w kolumnie email, aby dotrzeć do adresu email tych osób (tej osoby). Możemy też przesłać bezpośrednio adres email adresata.

Konfiguracja nadawcy

Obiekt, który zwracamy w metodzie build() klasy reprezentującej naszego maila, daje nam szeroki wachlarz metod których możemy użyć, aby precyzyjnie określić przeróżne aspekty naszego maila – np. nadawcę:

laravel-jak-wyslac-maila-okreslic-nadawce
Nadawcę określamy za pomocą metody from()

Używamy do tego metody from(). Oczywiście, jeśli wszystkie maile wysyłamy jako ten sam nadawca, definiowanie tego w każdej klasie reprezentującej maile mija się z celem. Dlatego w takiej sytuacje pomocny jest globalny plik konfiguracyjny, o którym wspominałem na początku wpisu – app/mail.php. Możemy tam dodać wpis, który określi nadawcę dla wszystkich naszych maili – będzie on użyty w każdej klasie rozszerzającej Mailable, o ile nie sprecyzujemy inaczej w klasie z konkretnym mailem. Tak samo możemy w pliku konfiguracyjnym określić stałe pole 'reply_to’ do użycia w całej aplikacji:

'from' => ['address' => 'kontakt@aplikacja.com', 'name' => 'Super Aplikacja'],
'reply_to' => ['address' => 'kontakt@aplikacja.com', 'name' => 'Super Aplikacja'],