 Moderator |
|
Uhm, ik hoop dat je niet overal rechtstreeks de mail() functie aanroept? Anders is dit alles "hardcoded" en zit er waarschijnlijk helaas niets anders op?
Wat wellicht beter is (of was geweest, lol), is een soort van abstractie/wrapper/hoe-je-het-ook-wilt-noemen: laat het verzenden van mail via een hulpklasse of -functie verlopen waaraan configuratie is gekoppeld? Dan kun je het configuratie "probleem" centraliseren en loskoppelen van het versturen van de mail zelf.
Daarmee zou je zelfs de werking van wat je mail-functionaliteit doet af kunnen laten van de omgeving waarin je deze aanroept. Hebben jullie nooit het probleem (gehad) dat je een testomgeving had met "live" data (bijvoorbeeld een geïmporteerd ledenbestand) waarbij dus mail-functionaliteit "op scherp" stond: als je mail verzond ging dit daadwerkelijk naar de buitenwereld?
Als je een wrapper hebt, dan kun je dit afvangen. Alle mail op een ontwikkel- of testomgeving zou je bijvoorbeeld naar een daarvoor bestemd test-adres kunnen sturen en de oorspronkelijke ontvanger kun je opnemen in een custom header (start met X-...). Zo kun je te allen tijde ook mail testen, zonder het risico dat iets naar klanten / eindgebruikers wordt gestuurd. |
Wat is jouw favoriete javascript framework? (S: 18, R: 2)
Gesponsorde links
Actiefste leden van de maand
