Send email with external web API rather than external SMTP

  • Hi,


    So my web host apparently disallows sending email from an external SMTP host for reseller accounts like mine. And I have a client that is using office 365 to manage their domain email, i cannot connect perch to the office365 SMTP nor can I use the local sendmail or connect to smtp locally. I could however use a web API such as SendGrid or others that offer the same service to send mail, but I'm pretty sure i would be bypassing the perch_forms email settings, auto responders etc.


    Is there anyway to override the Perch email send to use an other library other than PHPmailer so that the new class is used to send mail globally within Perch?


    Thanks.

  • drewm

    Approved the thread.
  • My problem is that the host doesn’t allow external smtp connections, so sending mail through smtp is out.


    If I could override the PerchEmail::send function I could connect to and use a web API like SendGrid to send mail. This is what I would like to know if it’s possible.

  • Ah.. that looks like it could work. It won't fire the event if an exception is thrown during the send procedure though. The best chance looks like if I default back to the sendmail settings, let it error and hopefully it errors out quietly. Sending through SMTP and phpMailer is probably going to throw an exceptions for sure.


    I'll try it out and see how it goes.


    Thanks!

  • I must be missing something here. I created a small app to handle the email.send event. If I send an email from the perch settings email diagnostic, my function is fired after the send as expected, but if I send from a public facing form that uses perch_forms, it doesn't get fired even though the email is sent.


    I have a runtime.php like:


    PHP
    1. <?php
    2. require_once('util/autoloader.php');
    3. include('util/events.php');


    and my events.php:


    PHP
    1. <?php
    2. $API = new PerchAPI(1.0, 'cognetif_apimail');
    3. $API->on('email.send', 'Cognetif\ApiMail\Manager::email_send');


    and finally Manager.php :




    Shouldn't the event get triggered when sending email through perch_forms ?

  • Here's my admin.php :


    I have debug break points throughout, none of them get triggered when sending a perch_forms form from the public site, but if i send the email diagnostic from the perch system, it works fine.

  • You're registering the listener in admin.php, which will catch any email events fired while you're using the control panel.


    If you also want to catch events fired when visitors are interacting with your pages, you'll need to register the listener in runtime.php and add your app to config/apps.php too.

  • So problem solved. I had it already in my runtime but in my testing, i had commented out the app in the apps.php :rolleyes:.. so of course it wasn't registering. Curious though that the app was still included in the Perch site though even though it wasn't included in the apps.php.



    Arg... sorry for wasting your time. Thanks Drew & Ryan for the awesome support as usual

  • Curious though that the app was still included in the Perch site though even though it wasn't included in the apps.php.

    Apps are always included in the control panel. apps.php is just a runtime performance optimisation. Saves Perch scanning for apps on every page load.

  • Unfortunately, all this seems to be for nothing as in my case, both sending via sendmail or phpmailer both throw an exception and therefore the event is not fired, it doesn't look like i have much options here to get mail sending.


    It would be cool if I could override PerchEmail.class.php to change the send function to:


    That way the event would be fired, and I could set the PERCH_EMAIL_METHOD to 'API' or something just not 'sendmail' or 'smtp' the rest would keep on working as usual.

  • drewm - since it doesn’t look like there is a way to send email if the tradition methods fail, do you think it would be possible to add and event handler : email.send_fail that passes the message object as a parameter?


    I don’t think that wouldn’t impact existing functionality and allow us to handle issues like this.


    I’d be happy to help implement and test .