[TYPO3-core] RFC #16911: Restructure of t3lib_utility_Mail hook subscriber

[Ernesto Baschny [cron IT]]

Jigal van Hemert schrieb am 04.01.2011 14:55:

> This is a SVN patch request.
> 
> Type: Bugfix / Clean up
> 
> BT reference: http://bugs.typo3.org/view.php?id=16911
> 
> Branches: trunk
> 
> Problem:
> t3lib_utility_Mail used callUserFunc for a hook. This hook was used to
> reroute all mails from that class to the new Swift Mailer. The result
> was an ugly class name and pretty messy code.
> 
> Solution:
> Ingo Renner supplied a nice interface and modified the hook to allow
> clean use of that interface.
> Changes of issue 16879 are included in this rewrite.
> A small fix for quoted display names is included.
> Some lengthy pieces of code and repeating code were moved to separate
> methods.
> 
> How to test:
> Make form content element and test with and without "HTML mode enabled"
> 
> Notes:
> Maybe t3lib/mail/class.tx_t3lib_mail_hooks.php needs to be renamed to
> t3lib/mail/class.t3lib_mail_swiftmaileradapter.php before applying the
> patch.
> Furthermore this file had Windows line endings; these have been changed
> to Unix line endings. Maybe this needs to be done before applying the
> patch if errors about failing chunks appear.

I reviewed this.

The new "parseAddresses" method was a bit buggy, which made it not
really send the From: header for example on a mail send (it was then
defaulting to "TYPO3 CMS <no-reply at example.org>").

To make it sure that it parses correctly, I made a quick unit test for
the parseAddresses method. Since it is a protected method, I made a mock
class with a public method for it that can be tested. This probably
looks ugly to the eyes of a PhpUnit experts, but I have no time to make
it more beautiful. Best would of course be a unit test that tests the
public API (which is only the "mail()" method), but this would then have
to parse the resulting mail an check that it is still the intended mail
=> difficult job.

So I reworked the parseAddresses a bit, also to make it more
understandable to me. Attached patch includes that and applies cleanly
on current trunk (no need to rename the file). Upon committing, the "svn
rename" should be used to rename the file instead of just deleting and
adding the new one.

+1 on reading and testing this.

Cheers,
Ernesto
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 16911-v2.diff
URL: <http://lists.typo3.org/pipermail/typo3-team-core/attachments/20110110/37ad1223/attachment-0001.asc>