After moving the website of my since-almost-the-first-day TYPO3 customer I realized that emails sent by the contact form would not reach their intended destination. After looking for a possible solution I realized that if TYPO3 had already been developed using dependency injection from the start, I'd now have a walk-over integrating a new mailer.
Of course, the Inversion of Control pattern hadn't even been formulated back then when Kasper developed the mail support for TYPO3. And the PEAR mail library was not really usable so that only a custom solution would allow direct mail to send well-formed emails. So this is no rant about TYPO3 but rather an affirmation that DI is the way to go.
The relocation of the domain was planned to be done in two steps: the first step was to move the website and secondly to move the email accounts. When I now send an email through the contact form on the new server, the local sendmail uses the new provider's mail server to send the email. Unfortunately this server feels responsible for the website's domain (because it will be the future mail server anyway) and therefore the emails don't reach their original recipient who is still accessing the old mail server.
The most simple solution would be to send emails via the old mail server. For that I'd need to tell TYPO3 to send emails through a specific SMTP host - but unfortunately t3lib_htmlmail passes emails directly to PHP's mail() function. Now, if dependency injection would already be in place since the beginning, I could easily create a new mailer class (for example based on Swift Mailer which is also used by FLOW3) and reconfigure the object container to use this implementation instead of the built-in mail class. Instantly all parts of TYPO3 and even all extensions which are totally unaware of Swift Mailer would use this new implementation because they get a mailer injected instead of referring to it with hardcoded class names.
Dependency Injection FTW!
Leave a reply