WireMail Mailgun

[Macrura]

16 hours ago, cb2004 said:

this supports the regions US and EU, would be great if you could get this into your fork.

i incorporated those elements, so those are in the module now; Should be tested by someone though, eu region on the forked version.

https://github.com/outflux3/WireMailMailgun/blob/master/WireMailMailgunConfig.php#L18-L27

https://github.com/outflux3/WireMailMailgun/blob/master/WireMailMailgun.module#L197-L205

[adrian]

Hey @Macrura - admittedly I haven't looked into this dynamic domain stuff much, but from what I can tell, I don't think it should be checked by default. With my setups it prevents emails from being sent.

What do you think?

[Macrura]

@adrian,

in order for dynamic domain to work, all of the domains have to be registered/validated in Mailgun. So for most uses the dynamic domain is not necessary. It shouldn't have been checked by default, if it was, i'll have to figure out how to make it not so.

This would only be useful for sites where you have identities that are sending from multiple domains; So for example if someone had a few forms, and one of the forms needed to have the sender email be a different domain than was entered in the form settings.

If you are in fact sending from a verified domain, and the mails are not being sent, can you check the mailgun log to see what the error code is?

Also, i should point out what happens if you don't use the dynamic domains, the emails will still go through, but will all be logged under the domain entered in the settings. The dynmaic domain just allows that config property, which is used for the CURL, to be changed on a per-message basis, setting the value of the api domain to the sender's domain (extracted from their email address). This files the messages under the correct domain logs in the Mailgun interface.

If it is not working, one possibility is that the code to extract the domain is not 100% working for all email address formats.

[adrian]

6 minutes ago, Macrura said:

in order for dynamic domain to work, all of the domains have to be registered/validated in Mailgun.

That makes sense - thanks.

7 minutes ago, Macrura said:

If you are in fact sending from a verified domain, and the mails are not being sent

Emails are sent just fine. I registered a mg.mydomain.com domain with Mailgun and if I use that in the module settings without dynamic domains, then everything works as expected.

9 minutes ago, Macrura said:

It shouldn't have been checked by default, if it was, i'll have to figure out how to make it not so.

I think it's simply because of the "value" parameter that is set in the WireMailMailgunConfig.php file. Actually speaking of the config settings, I think most of those checkbox settings should really have a value of "1" if they are to be checked by default, rather than the name of the field. Also, not sure what you think of the current approach to defining those module settings, but personally I prefer this approach (https://github.com/adrianbj/CookieManagementBanner/blob/master/CookieManagementBanner.config.php) if you want a separate file. No big deal either way - just seems cleaner to me. 

[Macrura]

i guess we do need to cleanup the checkboxes then, but i just copied the other checkbox config stuff for the new checkbox; I didn't realize that would make it checked by default; I guess this means that all of the checkboxes for this module are checked by default when you install;

[nbcommunication]

Hello,

We've been using Mailgun for several years now on ProcessWire developments, using a cURL implementation within a custom site development module/template site. I'm currently rewriting that and trying to use much more of the PW API  as there's been a lot of handy things added in the past while.

Part of that process is to use WireMailMailgun, so I installed @Macrura's fork and then began to see what could be improved/finished off from the todos.

What I've ended up doing is a partial rewrite of the module:

• to use more ProcessWire conventions and the coding style guide
• implemented a few extra features
• removed what I though was unnecessary code.

It requires 3.0.123 and above, as it uses the htmlToText() method from WireMail, which in turn uses WireTextTools. 

The module is here: https://github.com/chriswthomson/WireMailMailgun

Please let me know your thoughts!

Cheers,

Chris

[Macrura]

@nbcommunication

wow thanks for this, and especially for working on the todos and cleaning up the code! Looking forward to using your improved version.

[adrian]

Thanks @nbcommunication - could you please highlight the new features you've added?  I did a diff on yours vs @Macrura's but there are so many changes, it's hard to pick out what is new.

Thanks!

[nbcommunication]

Hi @adrian,

A lot of the code is much the same, but tidied up with the the coding style guide implemented, so I'm not surprised the diff doesn't reveal much!

The readme is pretty thorough and covers a lot, but here's the gist:

• addData() - add X-Mailgun-Variables - https://documentation.mailgun.com/en/latest/user_manual.html#attaching-data-to-messages - to be honest don't know what use cases there are for it but it's in the API and was easy to implement
• addTags() - add multiple tags as an array
• getHttpCode() - to get the response code from either send() or validateEmail() *
• Most methods now chainable (see the Advanced Example in the readme)
• Tracking only used if bodyHTML() is set (As this only works in HTML email)
• cc() and bcc() only used when batchMode is off - this seems to me to be the correct implementation 
• WireMail::htmlToText() used for generating the text version if only HTML passed (as in WireMail now)
• The ASCII conversion for tags now uses $this->sanitizer->nameFilter($tag, [" "], "", false, 128);
• WireMail::replyTo() implemented - doesn't seem to have been before
• removed addAttachment(), now uses WireMail::attachment() - which adds the ability to set the filename
• Unixtime is now passed to setDeliveryTime()
• A bunch of other small tweaks like using $sanitizer->email() in validateEmail()

* I'd wanted to use WireHttp for the requests, but it doesn't allow custom cURL options. I have done a pull request for this, but I don't think I'll be changing the module's cURL request implementation now anyway.

Cheers,

Chris

[adrian]

@nbcommunication - just wanted to say a big thanks for this new version - what are your plans to get this into the modules directory?

[nbcommunication]

I’m not really sure to be honest - I haven’t added anything to the directory before so will need to have a look through the process.

A couple of points:

- is it acceptable/desirable to have a module that’s only compatible with the lastest master (123) and beyond?

- ProMailer: I’ve not looked at this myself, and don’t expect to in the near future. My assumption is that Ryan has developed this to be compatible with the initial WireMailMailgun, which has differences in batchMode for cc/bcc - maybe this wouldn’t be an issue at all, I don’t know. 

I guess what I’m trying to say is that I’d be delighted to add it to the directory, but feel that the original should be retained. Perhaps the new version should be renamed? WireMailMailgun3?

Cheers,

 

Chris

[Macrura]

maybe I should just replace my version with @nbcommunication's code and then see about replacing the current module with mine in the directory, or alternately, if Chris wants to keep the new version under their purview, then they could replace it. I guess we need to ask Ryan to intervene here and be able to backend edit that module record to deprecate Pierre-Luc's version...

In terms of the compatibility, I'd say that it might be preferable to (if possible) run a version check and then only utilize functionality apropos the compatible version; I do think it is a problem to have a module that is in the directory that could possibly break an installation, though if the new version does state min version required, that should be enough to prevent users from inadvertently upgrading to an incompatible version...

[nbcommunication]

Agreed. I think that perhaps the best solution is for you to maintain the module, integrating anything applicable from my version. I’d be happy to help with this process.

 

[Macrura]

ok i'll be able to work on it starting next week, and will check back in here once i have something to report...

Doh! just checked the modules directory and Ryan already made the switch... thx @ryan! Will proceed with testing now for ensuring we don't break things with the refactored code, might take a week or so on this...

[simonGG]

Hi there,

i have installed the modul, opend an mailGun account and eveything works well except file attachment.
My code looks like this:

$m = $mail->new();
$m->to('someone@somewhere.com');
$m->from('me@myselfandi.com');
$m->subject('Test');
$m->addAttachment( $page->email_main_img->httpUrl );
$m->send();

Im wondering if i do something wrong here?

regards Simon

[gebeer]

2 minutes ago, simonGG said:

Im wondering if i do something wrong here?

The addAttachment method requires a file path on the disk, not an url. Try $m->addAttachment ( $page->email_main_img->filename );
See also https://processwire.com/api/ref/pageimage/filename/

[simonGG]

Thanks gebeer! Solved.  

[adrian]

@simonGG - I'd also recommend using @nbcommunication's fork (linked above) which handles attachments in a more PW way.

[simonGG]

@adrian - Thanks i checken the fork - looks good.

One little question: Is there anyway to embed Images and link them with CID?
I think about something like PHPMailer has: AddEmbeddedImage( $path, $cid, $name,... )

best regards
Simon

 

[adrian]

2 minutes ago, simonGG said:

@adrian - Thanks i checken the fork - looks good.

One little question: Is there anyway to embed Images and link them with CID?
I think about something like PHPMailer has: AddEmbeddedImage( $path, $cid, $name,... )

I am not that familiar with the Mailgun API to know if that's an option, but without knowing the details of what you are doing I would instead recommend an HTML formatted email with an `<img>` tag to embed the image from your web server - it's generally much better to do things this way.

[simonGG]

That's what im used to and i wanted it to realize it that way (used cleaverreace).
But the client dont accept that images not loaded automaticly (Outlook etc.)
So i see no other option in the moment.

[nbcommunication]

Having a look at https://documentation.mailgun.com/en/latest/api-sending.html#sending inline is a separate parameter that would need to be implemented. 

I’ll have a look at this on Monday when I’m back at the coalface. ?

Chris

[nbcommunication]

Hi,

I've added an addInlineImage() method to https://github.com/chriswthomson/WireMailMailgun

<?php

$img = $pages->get(1)->images->getRandom(); // An example
$customFilename = "test.$img->ext"; // Don't want to use the basename for this example
$mg = $mail->new();
$mg->to("your@email.com")
	->subject("Test Inline Image")
	->bodyHTML("<p>Testing, 123, is there an image for you to see?</p><img src='cid:$customFilename'>")
	->addInlineImage($img->filename, $customFilename) // Second argument is optional
	->send();

If the image isn't referenced in the HTML it just appears as a standard attachment from what I can see.

Cheers,

Chris

[simonGG]

nbcommunication

Sorry for the late reply (was totaly busy with another project) and a BIG THANKS for implementing this!

best regards

Simon

[dotnetic]

@nbcommunication Thanks for your work on this module. Maybe @Macrura could merge your latest changes? Would you create a pull request for this?

As far as I can see everything is working fine here. I use this module in conjunction with @ryan's ProMailer module to send out newsletters.

I even used the tags method, to enable analytics.