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

Hi,

I see Mailgun have updated their API to version 4. I'm going to implement this then submit my version to the directory as a separate module - no idea what to call it though... maybe WiremailMailgunApi.

Cheers,

Chris

EDIT: turns out that it is only the email validation that's been updated to version 4...!

  • 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 gebeer
      I am happy to present my new fieldtype FieldtypeImageFromPage. It is made up of 2 modules:
      Fieldtype Image Reference From Another Page is a Fieldtype that stores a reference to a single image from another page. The image can be selected with the associated Inputfield.
      Inputfield Select Image From Page is an Inputfield to select a single image from images on a predefined page and it's children.
      And there also is a helper module that takes care of cleanup tasks.
      This module evolved out of a discussion about my other Module FieldtypeImagePicker.  It caters for use cases where a set of images is being reused multiple times across a site. With this fieldtype these images can be administered through a chosen page. All images uploaded to that page will be available in the inputfield.
      When to use ?
      Let editors choose an image from a set of images that is being used site-wide. Ideal for images that are being re-used across the site.
      Suited for images that are used on multiple pages throughout the site (e.g. icons).
      Other than the native ProcessWire images field, the images here are not stored per page. Only references to images on another page are stored. This has several advantages:
      one central place to organize images when images change, you only have to update them in one place. All references will be updated, too. (Provided the name of the image that has changed stays the same) Features
      images can be manipulated like native ProcessWire images (resizing, cropping etc.) image names are fully searchable through the API orphaned references to images that get deleted are automatically removed. When you delete an image from one of the pages that hold your site-wide images, all pages that use this fieldtype will be searched. If any page contains a reference to the image you just deleted, that reference will be reset. You will get warning messages to edit those pages and add new image references there. How to install and setup
      Download and install this module like any other modules in ProcessWire Create a page in the page tree that will hold your images. This page's template must have an images field Upload some images to the page you created in step 2 Create a new field. As type choose 'Image Reference From Another Page'. Save the field. In 'Details' Tab of the field choose the page you created in step 2 Click Save button Choose the images field name for the field that holds your images (on page template from step 2) Click Save button again Add the field to any template You are now ready to use the field View of the inputfield on the page edit screen:

      View of the field settings

      The module can be installed from this github repo. Some more info in the README there, too.
      In my tests it was fairly stable. After receiving your valued feedback, I will eventually add it to the modules directory.
      My ideas for further improvement:
      - add ajax loading of thumbnails
      Happy to hear your feedback!
       
    • By gebeer
      Although the PW backend is really intuitive, ever so often my clients need some assistance. Be it they are not so tech savvy or they are not working in the backend often.
      For those cases it is nice to make some help videos available to editors. This is what this module does.
      ProcessHelpVideos Module
      A Process module to display help videos for the ProcessWire CMS. It can be used to make help videos (screencasts) available to content editors.
      This module adds a 'Help Videos" section to the ProcessWire backend. The help videos are accessible through an automatically created page in the Admin page tree. You can add your help videos as pages in the page tree. The module adds a hidden page to the page tree that acts as parent page for the help video pages. All necessary fields and templates will be installed automatically. If there are already a CKEditor field and/or a file field for mp4 files installed in the system, the module will use those. Otherwise it will create the necessary fields. Also the necessary templates for the parent help videos page and it's children are created on module install. The module installs a permission process-helpvideos. Every user role that should have access to the help video section, needs this permission. I use the help video approach on quite a few production sites. It is stable so far and well received by site owners/editors. Up until now I installed required fields, templates and pages manually and then added the module. Now I added all this logic to the install method of the module and it should be ready to share.
      The module and further description on how to use it is available on github: https://github.com/gebeer/ProcessHelpVideos
      If you like to give it a try, I am happy to receive your comments/suggestions here.
    • By Robin S
      A module created in response to the topic here:
      Page List Select Multiple Quickly
      Modifies PageListSelectMultiple to allow you to select multiple pages without the tree closing every time you select a page.
      The screencast says it all:

       
      https://github.com/Toutouwai/PageListSelectMultipleQuickly
      https://modules.processwire.com/modules/page-list-select-multiple-quickly/
    • By gebeer
      Hello all,
      sharing my new module FieldtypeImagePicker. It provides a configurable input field for choosing any type of image from a predefined folder.
      The need for it came up because a client had a custom SVG icon set and I wanted the editors to be able to choose an icon in the page editor.
      It can also be used to offer a choice of images that are used site-wide without having to upload them to individual pages.
      There are no image manipulation methods like with the native PW image field.
      Module and full description can be found on github https://github.com/gebeer/FieldtypeImagePicker
      Kudos to @Martijn Geerts. I used his module FieldTypeSelectFile as a base to build upon.
      Here's how the input field looks like in the page editor:

      Hope it can be of use to someone.
      If you like to give it a try, I'm happy to hear your comments or suggestions for improvement. Eventually this will go in the module directory soon, too.
    • By bernhard
      @Sergio asked about the pdf creation process in the showcase thread about my 360° feedback/survey tool and so I went ahead and set my little pdf helper module to public.
      Description from PW Weekly:
       
      Modules Directory: https://modules.processwire.com/modules/rock-pdf/
      Download & Docs: https://github.com/BernhardBaumrock/RockPDF
       
      You can combine it easily with RockReplacer: 
      See also a little showcase of the RockPdf module in this thread:
       
×
×
  • Create New...