Jump to content
Pierre-Luc

WireMail Mailgun

Recommended Posts

@jens.martsch - ok thanks for the report;

I haven't tested all elements of the new version – have you tested any other features, like the "dynamic domain" etc?

The main reason it has not been updated is because full testing of compatibility hasn't been done by me yet, and i was concerned about current users upgrading and possibly things failing silently...

Also I think the new version has a PW minimum requirement (3.0.123), and i haven't checked to see if the module config specifies, this, or what PHP versions the module is compatible with and putting in a minimum php version.

Share this post


Link to post
Share on other sites

Hey @Macrura I haven't tested "dynamic domains" because I don't use them, but the region setting for "EU" domain and also tracking for message open and clicks, which are working fine.

I also committed another patch for strange display behaviour in outlook: https://github.com/chriswthomson/WireMailMailgun/pull/14

Share this post


Link to post
Share on other sites

ok thanks, i'll be back on heavy module development in about a week or 2 and will be able to finally merge the versions and test and get this all sorted..

  • Like 1

Share this post


Link to post
Share on other sites
18 hours ago, jens.martsch said:

Hey @Macrura I haven't tested "dynamic domains" because I don't use them, but the region setting for "EU" domain and also tracking for message open and clicks, which are working fine.

I also committed another patch for strange display behaviour in outlook: https://github.com/chriswthomson/WireMailMailgun/pull/14

Hi @jens.martsch - I've merged your request.

I'd always thought that was the correct behaviour because if you send from a domain that isn't what you have in Mailgun (e.g. @test.com when @mg.test.com is your verified domain) then the "on behalf of" is the correct result. However, if one line fixes that, that's great!

Cheers,

Chris

  • Like 1

Share this post


Link to post
Share on other sites

@jens.martsch - thinking through it a little more, I think the addition of h:sender should only happen if the "from" domain is different to $this->domain. I'll pop that in place soon. I'd wondered whether using this would effect the DKIM auth etc but a few quick tests suggest that it doesn't 🙂.

@Macrura - I've been thinking about the Dynamic Domain setting, which I'd implemented based on your version but didn't give it much thought. Does it actually work without specifying the API key for the different domain? I wonder whether this could be removed and the following be the way to send from a different domain?

<?php

$mg = $mail->new();
$sent = $mg->to($to)
	->setDomainName("mg.differentdomain.com")
	->setApiKey($differentApiKey)
	->setRegion("eu") // If the region is different
	//->setSender("mg.differentdomain.com", $differentApiKey, "eu") // Alternative, region optional
	->subject($subject)
	->bodyHTML($message)
	->send();

Cheers,

Chris

  • Like 1

Share this post


Link to post
Share on other sites

On my account, i have many domains, all use same API key.

As I explained earlier in this thread, the only way to have send log entries go to the correct place in MG is to use the dynamic domain setting.

Sure, if you are able to use the API when sending, then using setDomainName() works, however API is not used when Form Builder is sending out emails from WireMail, or many other scenarios where mail is being sent by the system;

Without the dynamic domain setting enabled, your logs will be all messed up in MG, anytime FB auto responses are sent. Also, dynamic domain setting ensures you don't have to use setDomainName(), because even then, you'd still have to figure out which domain name to send from using the same code that is provided by the module...

 

 

Share this post


Link to post
Share on other sites

@Macrura - Thanks for the info. I wasn't thinking outwith explicit calls to WireMailMailgun, so that makes sense. I'll probably still add the setSender() and setRegion() functions though, might be useful to have.

Cheers,

 

Chris

  • Like 1

Share this post


Link to post
Share on other sites

How can I separate the api $mail->new call to the default wireMail when the MailGun Module is installed?

I use MailGun for the ProMailer Module, but have a few instances on the site, where mails are sent through the API. For instance the contact form now is using mailgun as well, but I don't want that. Is there an option to set the mailer to the default wireMail?

  • Like 1

Share this post


Link to post
Share on other sites

The Tracking of Mailgun did not work on my installation. I had to change the following:

private function clickTracking()
	{
		return ($this->trackClicks == 1) ? true : false;
	}

private function openTracking()
	{
		return ($this->trackOpens == 1) ? true : false;
	}

Don't know why it's a problem though. I'm using ProcessWire 3.0.123.

Share this post


Link to post
Share on other sites
On 6/2/2019 at 1:38 PM, Schwab said:

How can I separate the api $mail->new call to the default wireMail when the MailGun Module is installed?

I use MailGun for the ProMailer Module, but have a few instances on the site, where mails are sent through the API. For instance the contact form now is using mailgun as well, but I don't want that. Is there an option to set the mailer to the default wireMail?

Hi @Schwab - I'm not sure how this can be done, although given that there are a number of WireMail extension modules out there, I'm sure it must be possible and discussed previously. Might be worth having a look through the threads for WireMail SMTP etc to see if there is any info there.

4 hours ago, Schwab said:

The Tracking of Mailgun did not work on my installation. I had to change the following:


private function clickTracking()
	{
		return ($this->trackClicks == 1) ? true : false;
	}

private function openTracking()
	{
		return ($this->trackOpens == 1) ? true : false;
	}

Don't know why it's a problem though. I'm using ProcessWire 3.0.123.

I'm assuming this is @Macrura's version on the module repo - these methods came from the original "plauclair" version. I removed them entirely from my version as they were unnecessary, and didn't look like they would work anyway, given that trackClicks and trackOpens should be booleans (technically integers, but evaluate as either true or false).

I updated chriswthomson/WireMailMailgun last week with fallbacks etc, tested on 2.7.2 and above. Ended up moving straight onto another task and completely forgot to post!

  • Like 1

Share this post


Link to post
Share on other sites

Thanks @nbcommunication again for your continued work on this!

I should be able to work in next week and sort this whole thing out, with testing of dynamic domains and other functionality for QA.

As mentioned previously, the only reason I have not updated it is because I suspect that people may be running business-critical infrastructure with this module and any interruption to communication via email would be best to avoid.

And specifically you can see that a lot of people (including me) are not fully clear about how the Wiremail system works;

@Schwab's question illustrates this issue – you can't choose parts of the system to use different Wiremail implementations unless you have access to the API; Even then i'm not sure how the core selects which Wiremail module to use. For example, if you have WMMG installed and only want to use that from API calls, but also want to have WMSMTP running for Formbuilder, i don't think that is currently possible, though perhaps some hook magic would be the solution here...

Usually if I install WMMG on a site, I assume all mail will then be routed through the relevant Mailgun account, including Formbuilder submissions, as well as any custom email sends from modules, tracy notifications etc.; I have not played with having 2 separate Wiremail modules installed, because last time i tried that, it didn't seem to work though i don't have notes about why or what the issues were; I do know that different Wiremail modules were using different method names for the same thing, like attachments and that became tricky to manage when switching between WM modules...

 

Share this post


Link to post
Share on other sites
3 hours ago, Macrura said:

 

@Schwab's question illustrates this issue – you can't choose parts of the system to use different Wiremail implementations unless you have access to the API; Even then i'm not sure how the core selects which Wiremail module to use. For example, if you have WMMG installed and only want to use that from API calls, but also want to have WMSMTP running for Formbuilder, i don't think that is currently possible, though perhaps some hook magic would be the solution here...

Usually if I install WMMG on a site, I assume all mail will then be routed through the relevant Mailgun account, including Formbuilder submissions, as well as any custom email sends from modules, tracy notifications etc.; I have not played with having 2 separate Wiremail modules installed, because last time i tried that, it didn't seem to work though i don't have notes about why or what the issues were; I do know that different Wiremail modules were using different method names for the same thing, like attachments and that became tricky to manage when switching between WM modules...

 

I made a quick test to try the different options to get an instance of WireMail.

Like https://processwire.com/api/ref/wire-mail/ tells us, there are three options:

$m = $mail->new(); // option A
$m = wireMail(); // option B
$m = new WireMail(); // option C

With WireMailMailGun installed, option A and B are going out with WireMailMailGun.

Option C uses the native WireMail.

So for anyone using WireMailMailGun and wanting to send mails outside of MailGun, new WireMail() is the way to go.

  • Like 2

Share this post


Link to post
Share on other sites
6 minutes ago, Schwab said:

With WireMailMailGun installed, option A and B are going out with WireMailMailGun.

Option C uses the native WireMail. 

seems sort of inconsistent; i guess when using new WireMail() it sets up an object separate from the WM classes..... (?) maybe an undocumented feature...

Share this post


Link to post
Share on other sites
1 hour ago, Macrura said:

seems sort of inconsistent; i guess when using new WireMail() it sets up an object separate from the WM classes..... (?) maybe an undocumented feature...

This is related to https://github.com/processwire/processwire-issues/issues/733. Simply put new WireMail() specifically instantiates a WireMail object, not WireMailMailGun object, so this is (kind of) expected behaviour 🙂

Share this post


Link to post
Share on other sites

so it seems that modules that send email should always have a way of specifying which WireMail module to use. In other words, Formbuilder should have a setting which scans the installed WireMail modules, and allows the user to select which one to use for FB mails sent; Same for something like ProMailer.

The behind-the-scenes selection of which mail module gets used seems to be causing confusion among users, hence the questions on this thread and the issue #733.

It also seems possible to have multiple WireMail modules installed which would not conflict with each other, if you always specifically called the module you want to send with, instead of Option A, B or C.  I have not tested this theory, but i guess at some point soon there should be some codification of the whole thing...

 

  • Like 1

Share this post


Link to post
Share on other sites
11 hours ago, Macrura said:

so it seems that modules that send email should always have a way of specifying which WireMail module to use. In other words, Formbuilder should have a setting which scans the installed WireMail modules, and allows the user to select which one to use for FB mails sent; Same for something like ProMailer.

Depends: you could provide such option, but don't really have to. FormBuilder, for an example, simply makes use of the wireMail() function, so you're automatically using an installed ("third party") WireMail module instead of the default one (if one can be found – and if multiple are installed then the first one found).

When the WireMail module type was introduced all examples used this function, either directly sending messages using it, or instantiating a new WireMail object by calling it without arguments ("$mail = wireMail()"). Basically you should only ever use "new [WireMail class name]()" if you want to select a specific WireMail module instead of letting ProcessWire make that choice for you.

  • Like 1

Share this post


Link to post
Share on other sites

But what if you (like @Schwab) want a form to not use 3rd party module?

On 6/2/2019 at 8:38 AM, Schwab said:

I use MailGun for the ProMailer Module, but have a few instances on the site, where mails are sent through the API. For instance the contact form now is using mailgun as well, but I don't want that. Is there an option to set the mailer to the default wireMail?

If you were coding the contact from then yes, you'd be able to bypass the 3rd party module, but else you have no control over modules that always call the 3rd party WM module; And what if you have a few 3rd party modules installed and want to have control over which one is used and when, not using the API....

Share this post


Link to post
Share on other sites

Hey,

Launched a site today with a form that sends attachments and it turned out that our production server doesn't have mime_content_type() 🙁

https://github.com/chriswthomson/WireMailMailgun/pull/17

I've added a private method getMimeType() which checks first for mime_content_type(), then finfo_open(), then falls back to inferring based on file extension if neither exist.

This is based on https://www.php.net/manual/en/function.mime-content-type.php#87856 and https://gist.github.com/Erutan409/8e774dfb2b343fe78b14#file-mimetype-php

Also, a WireException is now thrown if an attachment has been added using WireMail::attachment() but curl_file_create() doesn't exist.

Cheers,

Chris

  • Like 1

Share this post


Link to post
Share on other sites

Hi all,

Is there any means to force MailGun as the wireMail 3rd party module?

A few days ago one of my sites stopped sending WireMailSMTP e-mails (couldn't connect to smtp.mailgun.org). There'd been no changes but I took it as an opportunity to switch over to this MailGun module that I use on several sites. 

When I'm using either FormBuilder, or my own code with '$message = wireMail();' for example, it doesn't use the MailGun module. Instead it tries to send using standard Wiremail which is picked up both on wiremaillogger and in cPanel. 

I simply cannot get it to call MailGun. Has anyone had this issue? I'm running PHP 7.1.

Thanks.

EDIT: It seems the issue is caused by the WireMailBranding module I still had installed. Uninstalling the module fixed this. It was never marked as compatible with 3.0 but did work until I updated to the latest MailGun module. I'll look further into it and see if there's a simple fix.

Share this post


Link to post
Share on other sites

@nbcommunication @Macrura

Sorry to bother, but could someone clarify what's the current state of this module? This thread contains posts about two separate versions, which are apparently not compatible – if the official version is still the one from Macrura, I think we should split posts about the "other version" to another thread if possible. Note that if that is to be done, it should really be released as a new module.

.. unless the plan is to make that the official version?

I'm currently starting a new project with this module, and had a bit of trouble figuring out which version to install 🙂

On 6/5/2019 at 3:30 PM, Macrura said:

But what if you (like @Schwab) want a form to not use 3rd party module?

That's a good point! To me it sounds like implementing a "Mailer picker" for each module separately would result in awful lot of duplicate work/code, though perhaps it would indeed be a reasonable feature for at least some of them (such as FormBuilder). I have never been in this situation, i.e. I've always used one mailing method per site, so not sure what would be the best approach.

One option would be providing a hookable method for sending the message, in which case this part could be overridden if deemed necessary 🙂

Share this post


Link to post
Share on other sites
1 hour ago, teppo said:

though perhaps it would indeed be a reasonable feature for at least some of them (such as FormBuilder)

FormBuilder has just such a setting:

2019-09-05_224155.png.c9d0d0e4a02556725eaaa7f5dd51e2bd.png

Although strangely if I change this setting it doesn't stick and always returns to "Auto-detect" - might be a bug.

For controlling the WireMail mailer used by other modules perhaps the recently released Mail Router module could be a solution. Although the module that is sending the mail can't be detected directly, for some circumstances you could perhaps use a prefix in the subject line (e.g. "Form submission: ...") that could determine which WireMail mailer is used.

  • Like 1

Share this post


Link to post
Share on other sites

@teppo

the modified version by @nbcommunication is supposed to replace the current version, but I was trying to find time to test it before replacing the code so as to not potentially have users upgrade and then have broken installations.

I just came across a problem with the current version, in that one of my business-critical sites suddenly seems to have lost the ability to send attachments using existing 'official' version;  so now i need to work on that - time is the only challenge now, but hoping to get to this within a minimum of the next week...

  • Like 1

Share this post


Link to post
Share on other sites
1 hour ago, Macrura said:

the modified version by @nbcommunication is supposed to replace the current version, but I was trying to find time to test it before replacing the code so as to not potentially have users upgrade and then have broken installations.

I just came across a problem with the current version, in that one of my business-critical sites suddenly seems to have lost the ability to send attachments using existing 'official' version;  so now i need to work on that - time is the only challenge now, but hoping to get to this within a minimum of the next week...

Thanks for the update! No worries, take your time – my current use case isn't particularly time-sensitive. I'm just happy to know what the long(er) term plan with the module is 🙂

Share this post


Link to post
Share on other sites

Hi,

The main breaking change with my version of the module is that Cc/Bcc is ignored if batch mode is set to on. Seemed absurd to me that an email sent to multiple addresses individually would be sent each time to any cc/bcc addresses set. 

The latest version is compatible with 2.7 onwards.  I implemented fallbacks for things (e.g. textTools) not present in the 2 branch. It also has more features and I've been using it in production without issue since I first posted it. However, I've not been using it for much more than sending simple emails. It's fully tested though 🙂 

I'd recommend using it if starting a new project, but I'm reluctant for it to be the main directory module as any users upgrading could encounter problems with their existing implementation. They'd be easy to fix, but that's not the point. I don't use any of the Pro modules that it integrates with (FormBuilder, ProMailer), and wouldn't want to interrupt "power" users of these.

Perhaps my version should have a different name? WireMailMailgun3 and I could remove the fallbacks for the 2 branch?

Cheers,

Chris

  • Like 1

Share this post


Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.


  • Recently Browsing   0 members

    No registered users viewing this page.

  • Similar Content

    • By eelkenet
      Hi! I've created a small Inputfield module called InputfieldFloatRange which allows you to use an HTML5 <input type="range" ../> slider as an InputField. I needed something like this for a project where the client needs to be able to tweak this value more based on 'a feeling' than just entering a boring old number. Maybe more people can use this so I'm hereby releasing it into the wild.  
       
      What is it?
      The missing range slider Inputfield for Processwire. 
      What does it do?
      This module extends InputfieldFloat and allows you to use HTML5 range sliders for number fields in your templates.
      It includes a visible and editable value field, to override/tweak the value if required.  
      Features
      Min/max values Precision (number of decimals) Steps (Read more) Manual override of the selected value (will still adhere to the rules above) Usage
      Clone / zip repo Install FieldtypeFloatRange, this automatically installs the Inputfield Create new field of type `Float (range)` or convert an existing `Float`, `Integer` or `Text` field. To render the field's value simply echo `$page->field` Demo
      A field with Min=0, Max=1, Step=0.2, Precision=2

      Field with settings Min=0, Max=200, Step=0.25, Precision=2

       
      Todo
      Make the display-field's size configurable (will use the Input Size field setting)  Hopefully become redundant If it's usable for others I'll add it to the Modules list  
      Changelog
      v002
      - Fix issue where setting the step value to an empty value created problem with validation
      - Make the display-field optional 
      v001
      - Initial release
       
      Thanks!
       
       
    • By Robin S
      Another little admin helper module...
      Template Field Widths
      Adds a "Field widths" field to Edit Template that allows you to quickly set the widths of inputfields in the template.

      Why?
      When setting up a new template or trying out different field layouts I find it a bit slow and tedious to have to open each field individually in a modal just to set the width. This module speeds up the process.
      Installation
      Install the Template Field Widths module.
      Config options
      You can set the default presentation of the "Field widths" field to collapsed or open. Field widths entered into the Template Field Widths inputfield are only applied if the Edit Template form is submitted with the Template Field Widths inputfield in an opened state. "Collapsed" is the recommended setting if you think you might also use core inputs for setting field widths in a template context. You can choose Name or Label as the primary identifier shown for the field. The unchosen alternative will become the title attribute shown on hover. You can choose to show the original field width next to the template context field width.  
      https://github.com/Toutouwai/TemplateFieldWidths
      https://modules.processwire.com/modules/template-field-widths/
    • By adrian
      Tracy Debugger for ProcessWire
      The ultimate “swiss army knife” debugging and development tool for the ProcessWire CMF/CMS

       
      Integrates and extends Nette's Tracy debugging tool and adds 35+ custom tools designed for effective ProcessWire debugging and lightning fast development
      The most comprehensive set of instructions and examples is available at: https://adrianbj.github.io/TracyDebugger
      Modules Directory: http://modules.processwire.com/modules/tracy-debugger/
      Github: https://github.com/adrianbj/TracyDebugger
      A big thanks to @tpr for introducing me to Tracy and for the idea for this module and for significant feedback, testing, and feature suggestions.
    • By adrian
      This module allows you to automatically rename file (including image) uploads according to a configurable format
      This module lets you define as many rules as you need to determine how uploaded files will be named and you can have different rules for different pages, templates, fields, and file extensions, or one rule for all uploads. Renaming works for files uploaded via the admin interface and also via the API, including images added from remote URLs.   Github: https://github.com/adrianbj/CustomUploadNames
      Modules Directory: http://modules.processwire.com/modules/process-custom-upload-names/
      Renaming Rules
      The module config allows you to set an unlimited number of Rename Rules. You can define rules to specific fields, templates, pages, and file extensions. If a rule option is left blank, the rule with be applied to all fields/templates/pages/extensions. Leave Filename Format blank to prevent renaming for a specific field/template/page combo, overriding a more general rule. Rules are processed in order, so put more specific rules before more general ones. You can drag to change the order of rules as needed. The following variables can be used in the filename format: $page, $template, $field, and $file. For some of these (eg. $field->description), if they haven't been filled out and saved prior to uploading the image, renaming won't occur on upload, but will happen on page save (could be an issue if image has already been inserted into RTE/HTML field before page save). Some examples: $page->title mysite-{$template->name}-images $field->label $file->description {$page->name}-{$file->filesize}-kb prefix-[Y-m-d_H-i-s]-suffix (anything inside square brackets is is considered to be a PHP date format for the current date/time) randstring[n] (where n is the number of characters you want in the string) ### (custom number mask, eg. 001 if more than one image with same name on a page. This is an enhanced version of the automatic addition of numbers if required) If 'Rename on Save' is checked files will be renamed again each time a page is saved (admin or front-end via API). WARNING: this setting will break any direct links to the old filename, which is particularly relevant for images inserted into RTE/HTML fields. The Filename Format can be defined using plain text and PW $page variable, for example: mysite-{$page->path} You can preserve the uploaded filename for certain rules. This will allow you to set a general renaming rule for your entire site, but then add a rule for a specific page/template/field that does not rename the uploaded file. Just simply build the rule, but leave the Filename Format field empty. You can specify an optional character limit (to nearest whole word) for the length of the filename - useful if you are using $page->path, $path->name etc and have very long page names - eg. news articles, publication titles etc. NOTE - if you are using ProcessWire's webp features, be sure to use the useSrcExt because if you have jpg and png files on the same page and your rename rules result in the same name, you need to maintain the src extension so they are kept as separate files.
      $config->webpOptions = array(     'useSrcExt' => false, // Use source file extension in webp filename? (file.jpg.webp rather than file.webp) ); Acknowledgments
      The module config settings make use of code from Pete's EmailToPage module and the renaming function is based on this code from Ryan: http://processwire.com/talk/topic/3299-ability-to-define-convention-for-image-and-file-upload-names/?p=32623 (also see this post for his thoughts on file renaming and why it is the lazy way out - worth a read before deciding to use this module). 
       
       
      NOTE:
      This should not be needed on most sites, but I work with lots of sites that host PDFs and photos/vectors that are available for download and I have always renamed the files on upload because clients will often upload files with horrible meaningless filenames like:
      Final ReportV6 web version for John Feb 23.PDF

×
×
  • Create New...