Hogyan KAPD EL a weboldalad által kiküldött ÖSSZES e-mailt?
Az igény egyértelmű: tesztelni szeretnénk, hogy a tartalomkezelő rendszerünkből/weboldalunkról kimenő levelek jó tartalommal állítódnak-e elő, megfelelő-e a formázásuk - csak a szokásos. Két irányba is indulhatunk, na de mi ez a kettő?
A két irány:
- egy más által üzemeltetett, online eszközt kezdünk el használni,
- vagy megoldjuk magunknak.
Ami mindkettőben közös, az a működési elv: a rendszerünkből kiküldött leveleket egy "igazi" SMTP szolgáltató helyett - mint amilyen pl. a Mailgun is - egy "kamu" SMTP szolgáltatót állítunk be a tartalomkezelő kimenő SMTP kapcsolatának. Ezután ez az ál-levelezőszerver nem csinál mást, mint elkap és megjelenít minden levelet, amit "hozzávág" az általunk fejlesztett weboldal.
Alább mindkettőre mutatok egy-egy példát, kezdjük az egyszerűbbel!
SaaS megoldás: Mailtrap
A Mailtrap használata egyszerű, a szokásos regisztrációt követően az alábbi felület fogad minket:
A Mailtrap több postaládát is képes kezelni, sőt, azokat más felhasználókkal is megoszthatjuk.
Itt válasszuk ki az egyetlen inboxot, ahol máris segítséget kapunk a beállításhoz - igaz, Ruby on Rails-ül, de ne rémüljünk meg, viszonylag egyszerű a dolgunk: csak másoljuk át értelemszerűen az adatokat a fejlesztői környezetünkbe, a korábbi SMTP beállítások helyére. Ezt követően már minden levelet itt fogunk látni, amit kiküld a rendszerünk.
Ha WordPress-t használunk, a legördülőből a WordPress-t választva egy olyan snippet generálódik, amit az mu-plugins mappába simán be tudunk dobni, az itteni példát követve.
Craft CMS esetén az ezen a linken található kódrészlet (amihez nyilván semmi közöm 😃) lesz segítségünkre.
A "szokásos" levelező elrendezést látjuk: bal oldalt jelennek meg a levelek, jobb oldalon pedig a tartalmuk, néhány hasznos információval.
A Mailtrap előnye tehát a könnyű beállítás, hátránya viszont, hogy csak 50 levél marad meg a fiókban (az ingyenes csomagban legalábbis).
Self-hosted: Mailhog
Ha ennyire egyszerű volt a Mailtrap beállítása, miért indulnánk el egyáltalán másik irányba? Például azért, mert helyi gépen szeretnénk tesztelni, ahol adott esetben egyáltalán nincs is internetkapcsolatunk: ilyenkor a kimenő levelezőszervert sem fogja ugyanis elérni a weboldalunk, így tesztelni sem tudunk majd.
Erre egy megoldás lehet a Mailhog, ami a Mailtrap-től elrendezésben csak egy kicsit különbözik: a felülete eggyel talán fapadosabb, de ezzel ebben az esetben nincsen problémám - kérdés nélkül teszi a dolgát, és ez a lényeg.
A Mailtrap-pal ellentétben itt inbox választás nélkül, azonnal listázódnak az elkapott e-mailek.
Nincs több postafiók, de nem is lenne értelme: a leveleket a Mailhog a memóriában tárolja, így újraindítás után a korábban fogadott levelek nem lesznek meg. Ez természetesen konfigurálható - részleteket a Mailhog dokumentációjában találsz.
A levelet a Mailhog esetében is meg tudjuk nézni mind HTML, mind plain text üzemmódban.
Hogyan üzemeljünk be egy Mailhog szervert?
Ha már amúgy is Docker-t használunk a fejlesztéshez, ennél mi sem lesz egyszerűbb: csak bővítsük ki az eddigi docker-compose.yml fájlunk services blokkját egy újabb szolgáltatással, az alábbi részletet felhasználva:
Ha még nincs docker-compose.yml fájlunk, az indításához akár használhatjuk egy az egyben az alábbi kódot:
Bármelyik eset is áll fenn, egy docker-compose up -d -t követően megtaláljuk a Mailhog-ot a localhost:8025-ös címen, és máris használhatjuk a tartalomkezelőnkben - a kapcsolódási adatok a következők lesznek:
- felhasználónév:
mailhog - jelszó:
mailhog - host:
mailhog(vagy ha más service nevet adtunk meg, akkor az) - port:
1025
Fontos: amikor élesíted az oldaladat, ne felejtsd el visszaállítani ezeket a beállításokat az "igazi" SMTP-kiszolgálód adataira. Ennél jobb lenne persze, ha a környezettől függően automatikusan érzékelné a rendszer, hogy melyik konfigurációt használja: Craft esetében ez a fent linkelt kódrészlettel megoldható, WordPress esetén pedig érdemes lehet ránézni a Bedrock-ra.
