WirePHPMailer

[ukyo]

PHPMailer for ProcessWire v3.

Module Directory - Github repo

I am author of WireMailPHPMailer. Old module using PHPMailer v5 and its extend WireMail base class. No more update will come for old version, but its still working :).

This module using PHPMailer v6 and not extending WireMail base class. This module integrating the PHPMailer mailing library into ProcessWire v3.

Usage almost same with original PHPMailer library (no need to include PHPMailer files).

Here is a simple example usage :

Using directly PHPMailer library

$mail = wire("modules")->get("WirePHPMailer");
$mail = $mail->mailer();
$mail->addAddress("email@domain.ltd", "Someone");
$mail->isHTML(true);
$mail->Subject = "WirePHPMailer";
$html = "<h1>WirePHPMailer</h1>";
$text = "WirePHPMailer";
$mail->Body    = $html;
$mail->AltBody = $text;
$mail->send();

Using module like classic WireMail

$mail = wire("modules")->get("WirePHPMailer");
$mail->from("from@domain.ltd")
    ->fromName("A From Name")
    ->to('email@domain.ltd')
    ->subject('A Message Subject')
    ->body('A Message Body')
    ->bodyHtml("<h1>A HTML Message Body")
    ->send();

Note : This module requires InputfieldHelper, PHP>=5.6.0, ProcessWire>=3.0.0 module.

[adrian]

@ukyo - thanks for your work on this! Please don't take this as a criticism - it's an honest question - why did you decide to not extend WireMail? I am sure you have a good reason. 

I think there might be other reasons as well, but the first limitation I see is that Tracy's Mail Interceptor won't work with this, nor will the new Mail Debugger module.

My other question is about your choice to make InputfieldHelper a requirement. I read through the support thread for that module and I still don't get it. I am sure I am missing something and it is probably very useful for certain tasks, but I do think it will be a barrier for getting people to install your WirePHPMailer module, especially when there is already three other working mail modules. Perhaps if you could better explain the advantages to this over those other mail modules, it might help.

Cheers!

[teppo]

33 minutes ago, adrian said:

[...] the first limitation I see is that Tracy's Mail Interceptor won't work with this, nor will the new Mail Debugger module.

Have to agree with this. The biggest benefit with WireMail modules is that they unify the way email is sent within ProcessWire, and thus allow both third party modules (like Tracy, Mail Debugger, and a number of others) and built-in core features to a) automatically benefit from installed WireMail modules, and b) hook into that process in a consistent way if need be.

I'd say that unless you've got a very good reason not to extend WireMail, you really should.

That being said, thanks for your work on this module. 

[Macrura]

I can see one possible advantage to not extending WireMail – the ability to ad-hoc switch mailing system when you send an api email.

For example, some of the emails in one list i'm sending to are being bounced due to the Mailgun server ip address; i can't switch to another wiremail email since Mailgun is extending Wiremail and then wiremail is using Mailgun... if i understand this correctly. With this module, i could just instantiate it and send using it, and avoid any conflicts with WireMail (?)

[cstevensjr]

2 hours ago, Macrura said:

I can see one possible advantage to not extending WireMail – the ability to ad-hoc switch mailing system when you send an api email.

For example, some of the emails in one list i'm sending to are being bounced due to the Mailgun server ip address; i can't switch to another wiremail email since Mailgun is extending Wiremail and then wiremail is using Mailgun... if i understand this correctly. With this module, i could just instantiate it and send using it, and avoid any conflicts with WireMail (?)

You could easily switch the mail provider or the Module extending WireMail.

A downside of not using one of the big mail providers is the real chance that your email will be seen as spam on certain receiving hosts or mail providers.  The mail reputation score matters when sending any email.  

I guess the real deal with using PHPMailer, in my opinion, is are you sending out using a properly configured SMTP gateway or not.

[ukyo]

4 hours ago, adrian said:

@ukyo - thanks for your work on this! Please don't take this as a criticism - it's an honest question - why did you decide to not extend WireMail? I am sure you have a good reason. 

I think there might be other reasons as well, but the first limitation I see is that Tracy's Mail Interceptor won't work with this, nor will the new Mail Debugger module.

My other question is about your choice to make InputfieldHelper a requirement. I read through the support thread for that module and I still don't get it. I am sure I am missing something and it is probably very useful for certain tasks, but I do think it will be a barrier for getting people to install your WirePHPMailer module, especially when there is already three other working mail modules. Perhaps if you could better explain the advantages to this over those other mail modules, it might help.

Cheers!

3 hours ago, teppo said:

Have to agree with this. The biggest benefit with WireMail modules is that they unify the way email is sent within ProcessWire, and thus allow both third party modules (like Tracy, Mail Debugger, and a number of others) and built-in core features to a) automatically benefit from installed WireMail modules, and b) hook into that process in a consistent way if need be.

I'd say that unless you've got a very good reason not to extend WireMail, you really should.

That being said, thanks for your work on this module. 

I don't have any reason for not extending base WireMail class. This is why i updated module and now module extending bas WireMail class.

Now you have 2 usage types:

1. Use directly PHPMailer class

2. Use extended send method

Quote

My other question is about your choice to make InputfieldHelper a requirement.

For InputfieldHelper requirement, its easy to create configurable modules with this module and usable module for many cases, i won't remove requirement of this module.

Quote

Perhaps if you could better explain the advantages to this over those other mail modules, it might help.

Like i mentioned, i am author of WireMailPHPMailer, i am not caring about module usage statics, if someone need PHPMailer module, they can use it.

- I tested swift mailer module (smtp)

- I tested base WireMail class (smtp)

- I tested mailgun (curl)

I am not prof. of mail sending but when i make simple mail send tests with same settings (mailgun not included), https://www.mail-tester.com/ test result not ok for me (problem with DKIM). My test result with PHPMailer 10/10, this is why i am using PHPMailer library with my modules.

[adrian]

Thanks for changing it to extend WireMail!

I am curious why PHPMailer would result in better scores at mail-tester.com than WireMailSmtp or WireMailSwiftMailer. Do you have any idea why?

[ukyo]

5 minutes ago, adrian said:

Thanks for changing it to extend WireMail!

I am curious why PHPMailer would result in better scores at mail-tester.com than WireMailSmtp or WireMailSwiftMailer. Do you have any idea why?

I tested them long time ago, before i wrote my first Mail module and i think there is problem getting DKIM.

[teppo]

@ukyo: first of all, thanks for extending WireMail. I think this makes your module more useful in the long run.

Now, sadly there's a bit of a downside to this: a week ago Ryan pushed an update to the dev branch (related to this issue) that changed the way WireMail modules are found by the core. In short, the class name must now start with "WireMail". One can get past this auto-detection feature by manually specifying (in a config setting) the name of the WireMail module to use, but in order to work optimally both now and in the future, I'd still consider renaming this module to something that starts with "WireMail".

Thanks again, and sorry for the trouble

[adrian]

To follow up from @teppo's point - is there any reason your old WireMailPHPMailer need to exist? I assume it's because PHPMailer 6 requires PHP 5.5? It sounds like Ryan might be moving PW to a 5.5 minimum sometime shortly, so maybe it's ok moving forward.

[ukyo]

6 hours ago, teppo said:

@ukyo: first of all, thanks for extending WireMail. I think this makes your module more useful in the long run.

Now, sadly there's a bit of a downside to this: a week ago Ryan pushed an update to the dev branch (related to this issue) that changed the way WireMail modules are found by the core. In short, the class name must now start with "WireMail". One can get past this auto-detection feature by manually specifying (in a config setting) the name of the WireMail module to use, but in order to work optimally both now and in the future, I'd still consider renaming this module to something that starts with "WireMail".

Thanks again, and sorry for the trouble

 

6 hours ago, adrian said:

To follow up from @teppo's point - is there any reason your old WireMailPHPMailer need to exist? I assume it's because PHPMailer 6 requires PHP 5.5? It sounds like Ryan might be moving PW to a 5.5 minimum sometime shortly, so maybe it's ok moving forward.

 I updated WireMailPHPMailer module to PHPMailer v6. I will update WireMailPHPMailer support post.

I have request for deletion of this topic and WirePHPMailer from module directory.

[adrian]

3 minutes ago, ukyo said:

 I updated WireMailPHPMailer module to PHPMailer v6. I will update WireMailPHPMailer support post.

I have request for deletion of this topic and WirePHPMailer from module directory.

Thanks @ukyo - I have deleted that new module from the directory. Not sure about deleting this topic though - I think it's still a worthwhile discussion - perhaps it might be worth editing the opening post to note what's happened?

[ukyo]

Thanks for feedbacks !