Feature #24841: Defining a custom MailTransport which implements SwiftTransport - TYPO3 Core - TYPO3 Forge

Actions

Copy link

Feature #24841

closed

Defining a custom MailTransport which implements SwiftTransport

Added by Claus Due almost 14 years ago. Updated about 6 years ago.

Status:

Closed

Priority:

Should have

Assignee:

Category:

Target version:

Start date:

2011-01-26

Due date:

% Done:

100%

Estimated time:

PHP Version:

5.3

Tags:

Complexity:

Sprint Focus:

Description

Hi guys,

Wonderful work on 4.5 so far. I would like to request a feature (or rather behavior change) in the core mailer of TYPO3. I have attached a .diff file which changes the default case in the switch on $GLOBALS['TYPO3_CONF_VARS']['MAIL']['transport'] to detect a user-specified extension class implementing SwiftTransport - which is then able to act as the default mail transport for TYPO3.

The default behavior in this patch is to throw an exception on an unknown transport definition - the default maybe should be to use the default TYPO3 transport as in case "mail".

This is as far as I can tell ~~the~~ way to go when replacing the basic way emails are sent, for example letting the administrator implement a SOAP-based offsite email sending solution; which is what I'm trying to do.

Patch created on 4.5rc2

(issue imported from #M17345)

Files

Download all files

class.t3lib_mail_mailer.php.diff (521 Bytes) class.t3lib_mail_mailer.php.diff		Administrator Admin, 2011-01-26 19:16
class.t3lib_mail_mailer.php.2.diff (493 Bytes) class.t3lib_mail_mailer.php.2.diff		Administrator Admin, 2011-01-26 19:42

Related issues 1 (0 open — 1 closed)

Actions

Copy link

Updated by Claus Due almost 14 years ago

Note: this could possibly also be solved by using the provided custom transport name to override the default MailInvoker used by SwiftMailer - actually, that seems like a better solution. Attached is a .diff exploring that method.

Actions

Copy link

Updated by Claus Due almost 14 years ago

Sorry for the corrections, but it appears I found a developer-friendlier way of doing this:
Before setting $this->transport, inside the default case:
$invokerClassName = $mailSettings['transport'];
if ($invokerClassName != 'mail') {
Swift_DependencyContainer::getInstance()->register('transport.mailinvoker')->asSharedInstanceOf($invokerClassName);
}

Actions

Copy link

Updated by Ernesto Baschny almost 14 years ago

Very interesting feature! I guess we will have more t3lib_mail API enhancements for 4.6, and this is definitively one to consider.

Sorry that we didn't have time to include it in 4.5. But 4.6 will be out in October.

Consider opening a thread in the teams.projects.v4 newsgroup / mailing list about enhancing the t3lib_mail API! Jigal and myself will gladly join the discussion.

Actions

Copy link