Project

General

Profile

Actions

Feature #64047

closed

extbase mail wrapper for core mail; ActionMailer

Added by Pascal Dürsteler almost 10 years ago. Updated over 4 years ago.

Status:
Closed
Priority:
Should have
Assignee:
-
Category:
Extbase
Target version:
-
Start date:
2014-12-27
Due date:
% Done:

0%

Estimated time:
PHP Version:
Tags:
Complexity:
Sprint Focus:

Description

The current way to go when implementing mail delivery in an extbase extension seems to be http://wiki.typo3.org/How_to_use_the_Fluid_Standalone_view_to_render_template_based_emails. Peeking at out ActionController, extbase could provide the same architecture for looking up and rendering mails.

I'm just throwing my idea in here with a bit of pseudo-code, as this may explain things better than when writing it out. IMHO this would help extension developers to concentrate on building their extension and spare a lot of time writing / copy-pasting code to handle mail deliveries.

File structure

typo3conf/ext/<myext>
  - Classes
    - Mailer
      - MyMailer.php
  - Resources
    - Private
      - Templates
        - MyMailer

MyMailer.php

class MyMailer extends \TYPO3\CMS\Extbase\Mailer\ActionMailer {
    public function welcomeUserMail($user) {
        /** @var \TYPO3\Core\Mail\Message */
        $mail = $this->createMail();

        /* 
          * ActionMailer base class sets layout and template automagically
          * based on the current controller name and action name; This e.g. would be 
          *
          *   $templateRootPath/@MailerClassName/@MailerMethodName.html
          *
          * The only thing you actually do in here is set / assign data, similiar to the controller.
          */

        $mail->setTo($user->getEmail());
        $mail->setSubject('Successfully signed up!');
        $mail->assign('user', $user); // Exposed to the fluid standalone view
        return $mail->send();
    }
}

MyController.php

public function confirmationAction() {
    // ... creating $user ...

    $mailer = makeInstance('MyMailer'); // or maybe instantiate it through DI's @inject?
    $mailer->welcomeUserMail($user);
}


Related issues 1 (0 open1 closed)

Related to TYPO3 Core - Feature #90266: Fluid-based templated emailsClosedBenni Mack2020-01-31

Actions
Actions #1

Updated by Pascal Dürsteler almost 10 years ago

Sorry for the broken link above, missed a space. It should be http://wiki.typo3.org/How_to_use_the_Fluid_Standalone_view_to_render_template_based_emails

Actions #2

Updated by Chris topher almost 10 years ago

  • Description updated (diff)
Actions #3

Updated by Markus Klein almost 10 years ago

Just a note from my side: We need multilanguage and plaintext support for mails. So our current structure looks like this:

Resources/Private/MailTemplates/<lang-iso-2-code>/<controller>/mailtemplate.html
Resources/Private/MailTemplates/<lang-iso-2-code>/<controller>/mailtemplate.txt

The subject of the mail is the first line of the txt-file.

We use standalone view to load the template and a viewhelper to embed images in the HTML mail.

Actions #4

Updated by Pascal Dürsteler almost 10 years ago

Multilanguage is required, that's for sure. But your structure seems a bit off for me, as this would be the only place with such a structure. By now, we only have one html template for views (the "usual" views are meant here) and localize through f:translate and its according xliff/xml files. Why not stick with that to keep it consistent?

Actions #5

Updated by Markus Klein almost 10 years ago

Well, this structure is necessary as you do not want to translate huge mails bit by bit via xliff.

An email is generally different compared to a web output, where mostly single labels need to be translated.
In emails you generally have lots of text to be translated with potentially formatting differences, so it is way easier to translate a whole file.
Moreover you may need to adjust a lot of links in the mail to include the L parameter for the specific language.

Actions #6

Updated by Xavier Perseguers over 9 years ago

There's an additional usual requirement when sending localized emails. Namely that you should be able to override the language, typically in a BE context where e.g., an editor is using a module to send mails to users and those emails should match the preferred language of the recipient, not the sender.

Actions #7

Updated by Markus Klein over 9 years ago

Full ACK!

I have a private mail api based on Fluid templates, which supports all that.

Actions #8

Updated by Georg Ringer over 4 years ago

  • Status changed from New to Resolved

we have now FluidEmail with #90266. therefore I am closing this generall issue. it might not yet support every edgecase but is a good start. feel free to open dedicated issues for stuff which is missing.

Actions #9

Updated by Georg Ringer over 4 years ago

Actions #10

Updated by Benni Mack over 4 years ago

  • Status changed from Resolved to Closed
Actions

Also available in: Atom PDF