-
Notifications
You must be signed in to change notification settings - Fork 71
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
TEmail subclass of TPage for rendering emails through TTemplate. sent via TEmailerModule #760
Comments
I usually use composer to include https://swiftmailer.symfony.com/. |
thank you for this. |
I'll look into other platforms like drupel and wordpress on how they do email. I know WP has a central email function that relies on phpmailer. my memory isn't great about where that code lives in the architecture of the system. |
I'm thinking of a TEmailerModule that does the initialization of SwiftMail. TEmailerModule could create the email body from TTemplates (or pages), incorporate images/files automagically, etc. This could have its own directory in Prado\Util like Prado\Util\Email A behavior can be made to append the emailer module to TApplication to act and have getters like Globalization or Request. |
I have an idea. How about the Emailer function as a Behavior that attaches to Application? Example below. A new TEmailTemplate class would capture published files and re-route them to TEmail. TEmail is a subclass of TPage (as the email body) but with To, From, Subject, CC, BCC, etc and without anything regarding the request and response. An Email would work just like a page, as a TTemplateControl (subclass). The Email file would be a "*.email" with the optional implementing "TEmail" php class of the same name. The below code has not been run or tested but is provided for example and commentary at this point. Basically, it's an application wide email assist function. It does a basic validation on the subject for \n or \r. It accepts text, html text, or combined [$html, $text] array. It automatically checks the $message for or tags to trigger HTML style emails. It automagically sets headers that aren't set: To, From, Reply-To, Content-Type, and MIME-version. If the behavior encodes that all outgoing emails have a CC or BCC, they can be specified in the behavior. Lastly, HTML messages without text versions are stripped of HTML tags and html entities are converted to create a text based version of the HTML automatically. The Most Important piece, after all that email automation, is the event to reroute the email to a different component in the system via the event OnSendEmail. The handlers can cancel sending email by returning something other than null. If the email is handled by a handler and cancels the default emailer, return false if it did not work and true if it did. Lastly, the email html and attachments are post processed into an email body and sent via PHP mail function if not handled by the OnSendMail. This is a basic email processor. OnSendMail could reroute emails to a SwiftMail or phpMailer PRADO Module.
|
The vision I have is to use a TTemplate to generate an email body. What would come from this? Here is my first pass: I new "Email" directory would act similarly to the "Pages" directory. Emails are accessed via paths like a Page is accessed. eg "Registration.Welcome" in folder "Registration" and template "Welcome." TEmail would have a ".email" extension and would act/subclass as a TPage, as in: having an implementation php class. TEmail should have all the standard Email properties, To, From, CC, BCC, Subject. TEmailerBehavior would attach to the TApplication and act like a TService and provide Default From address, CC and BCC addresses for all emails. It provides SendEmail and CreateEmail behavior functions to TApplication. This behavior should have embedded configurations for setting a pages' [an emails'] default MasterClass, and such, like TPageService has for xml tags "pages" and "page", etc. The TEMailerBehavior accepts an email similar to php mail. $message can be text, html, or an array of [$html, $text]. If only HTML is provided, the text version is derived from the html. Sending mail raises the "onSendMail" event to handle, log, filter, or do something with the email. If not handled, it renders the email and sends it by php mail function. A simple module can be written for rerouting emails through OnSendMail handlers to swiftmail or phpmailer and cancel the default mail handler. all elements of the email (like attachments) are sent to the handler as well. Email folder should have configuration files in the Email Folder as well, like Pages. But emails do not need authorization rules. So TPageConfiguration can be updated to parameterize the name of the "pages" and "page" and doing authorization rules. TEmailConfiguration can turn off authorization rules and change "pages" to "emails" and "page" to "email." TEmailTemplate is a subclass of TTemplate that acts as a rerouter for publishing files to be either URLs, attached to the email, or embedded when specified. Default to URLs. so an TEmail acts like a TPage. |
It's morphed from a complex behavior into a TEmailerModule that acts like a TPageService but without dependency upon Service, Request, and Response. Defaults to sending by php mail(). It cleans up the headers. The TEmailerBehavior for TApplication is 3 methods (createEmail, sendMail, and sendEmail) and a property (EmailerModule) and acts as a pass-through. Emails are configured like pages. For example, default "From" and "MasterClass" is set in configuration with a I think a TPhpMailerBehavior for TEmailerModule should be included in the framework for a SMTP email solution. obviously, the user would have to require the email composer package to use the behavior. email behaviors would open up respective mail objects given configuration parameters for/upon sending the email. There is a parameter as to whether or not there are many emails and to retain the object and mail connection. So far here are the new classes: TEmailConfiguration, TEmailerBehavior, TEmailerModule,, TEmailEventParameter, TEmail,, TEmailTemplate, TEmailPublishStyle. Here are the edits to existing classes: TEmailLogRoute checks the Application for method "sendMail" and uses that before defaulting to php mail(). TPageConfiguration parameterizes processing authorization rules, "pages" and "page" tags. It also moves some functionality into methods for broader use. TTemplateManager needs to a $tplClass to be able to instance a sub-class of TTemplate and a [non-request based] $culture parameter. |
One of the major functions that modern applications have is send emails. Emails are sent out when users register, forget their username or password, 2FA, news letters, etc.
Emailing is handled in each application separately. There should be a centralized place for sending (and possibly routing) app emails. the default behavior should be to php mail function.
`
/**
* This sends an email within the system. dySendEmail allows
* behaviors to divert this function to a more advanced email system
* @param string $from
* @param string[]|string $to
* @param string $subject
* @param string $contents
* @param array $options
*/
public function sendEmail($from,$to,$subject,$content,$options=null)
{
if (!is_array($options)) {
$options=array();
}
`
This can be the stub to start adding other features like multibyte character support. This function could probably be upgraded significantly. When dySendEmail is implemented by a behavior, to bypass sending email, return true from the dynamic event.
Should this go in TApplication? Should this be its own component? I don't see why or how this would or could become its own component, though I am open to suggestions. Such a simple function doesn't need anything complex.
Should phpMailer be incorporated to send emails? maybe phpMailer could be a separate TModule. I do have a separate Plugin Module for sending emails in a cron job and logging emails to a database with PHPMailer. I'm planning on making this emailer plugin available at some point. but it also would handler the above dynamic method.
The text was updated successfully, but these errors were encountered: