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

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

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 Robin S
      Repeater Images
      Adds options to modify Repeater fields to make them convenient for "page-per-image" usage. Using a page-per-image approach allows for additional fields to be associated with each image, to record things such as photographer, date, license, links, etc.
      When Repeater Images is enabled for a Repeater field the module changes the appearance of the Repeater inputfield to be similar (but not identical) to an Images field. The collapsed view shows a thumbnail for each Repeater item, and items can be expanded for field editing.
      Screencast

      Installation
      Install the Repeater Images module.
      Setup
      Create an image field to use in the Repeater field. Recommended settings for the image field are "Maximum files allowed" set to 1 and "Formatted value" set to "Single item (null if empty)". Create a Repeater field. Add the image field to the Repeater. If you want additional fields in the Repeater create and add these also. Repeater Images configuration
      Tick the "Activate Repeater Images for this Repeater field" checkbox. In the "Image field within Repeater" dropdown select the single image field. You must save the Repeater field settings to see any newly added Image fields in the dropdown. Adjust the image thumbnail height if you want (unlike the core Images field there is no slider to change thumbnail height within Page Edit). Note: the depth option for Repeater fields is not compatible with the Repeater Images module.
      Image uploads feature
      There is a checkbox to activate image uploads. This feature allows users to quickly and easily add images to the Repeater Images field by uploading them to an adjacent "upload" field.
      To use this feature you must add the image field selected in the Repeater Images config to the template of the page containing the Repeater Images field - immediately above or below the Repeater Images field would be a good position.
      It's recommended to set the label for this field in template context to "Upload images" or similar, and set the visibility of the field to "Closed" so that it takes up less room when it's not being used. Note that when you drag images to a closed Images field it will automatically open. You don't need to worry about the "Maximum files allowed" setting because the Repeater Images module overrides this for the upload field.
      New Repeater items will be created from the images uploaded to the upload field when the page is saved. The user can add descriptions and tags to the images while they are still in the upload field and these will be retained in the Repeater items. Images are automatically deleted from the upload field when the page is saved.
      Tips
      The "Use accordion mode?" option in the Repeater field settings is useful for keeping the inputfield compact, with only one image item open for editing at a time. The "Repeater item labels" setting determines what is shown in the thumbnail overlay on hover. Example for an image field named "image": {image.basename} ({image.width}x{image.height})  
      https://github.com/Toutouwai/RepeaterImages
      https://modules.processwire.com/modules/repeater-images/
    • By EyeDentify
      Hello There Guys.

      I am in the process of getting into making my first modules for PW and i had a question for you PHP and PW gurus in here.

      I was wondering how i could use an external library, lets say TwitterOAuth in my PW module.
      Link to library
      https://twitteroauth.com/

      Would the code below be correct or how would i go about this:
      <?PHP namespace ProcessWire; /* load the TwitterOAuth library from my Module folder */ require "twitteroauth/autoload.php"; use Abraham\TwitterOAuth\TwitterOAuth; class EyeTwitter extends WireData,TwitterOAuth implements Module { /* vars */ protected $twConnection; /* extend parent TwitterOAuth contructor $connection = new TwitterOAuth(CONSUMER_KEY, CONSUMER_SECRET, $access_token, $access_token_secret); */ public function myTwitterConnection ($consumer_key, $consumer_secret, $access_token, $access_token_secret) { /* save the connection for use later */ $this->twConnection = TwitterOAuth::__construct($consumer_key, $consumer_secret, $access_token, $access_token_secret); } } ?> Am i on the right trail here or i am barking up the wrong tree?
      I don´t need a complete solution, i just wonder if i am including the external library the right way.
      If not, then give me a few hint´s and i will figure it out.

      Thanks a bunch.

      /EyeDentify
    • By dimitrios
      Hello,
      this module can publish content of a Processwire page on a Facebook page, triggered by saving the Processwire page.
      To set it up, configure the module with a Facebook app ID, secret and a Page ID. Following is additional configuration on Facebook for developers:
      Minimum Required Facebook App configuration:
      on Settings -> Basics, provide the App Domains, provide the Site URL, on Settings -> Advanced, set the API version (has been tested up to v3.3), add Product: Facebook Login, on Facebook Login -> Settings, set Client OAuth Login: Yes, set Web OAuth Login: Yes, set Enforce HTTPS: Yes, add "http://www.example.com/processwire/page/" to field Valid OAuth Redirect URIs. This module is configurable as follows:
      Templates: posts can take place only for pages with the defined templates. On/Off switch: specify a checkbox field that will not allow the post if checked. Specify a message and/or an image for the post.
      Usage
      edit the desired PW page and save; it will post right after the initial Facebook log in and permission granting. After that, an access token is kept.
       
      Download
      PW module directory: http://modules.processwire.com/modules/auto-fb-post/ Github: https://github.com/kastrind/AutoFbPost   Note: Facebook SDK for PHP is utilized.


    • By kongondo
      FieldtypeRuntimeMarkup and InputfieldRuntimeMarkup
       
      Modules Directory: http://modules.processwire.com/modules/fieldtype-runtime-markup/
      GitHub: https://github.com/kongondo/FieldtypeRuntimeMarkup
      As of 11 May 2019 ProcessWire versions earlier than 3.x are not supported
      This module allows for custom markup to be dynamically (PHP) generated and output within a page's edit screen (in Admin).
       
      The value for the fieldtype is generated at runtime. No data is saved in the database. The accompanying InputfieldRuntimeMarkup is only used to render/display the markup in the page edit screen.
       
      The field's value is accessible from the ProcessWire API in the frontend like any other field, i.e. it has access to $page and $pages.
       
      The module was commissioned/sponsored by @Valan. Although there's certainly other ways to achieve what this module does, it offers a dynamic and flexible alternative to generating your own markup in a page's edit screen whilst also allowing access to that markup in the frontend. Thanks Valan!
       
      Warning/Consideration
      Although access to ProcessWire's Fields' admin pages is only available to Superusers, this Fieldtype will evaluate and run the custom PHP Code entered and saved in the field's settings (Details tab). Utmost care should therefore be taken in making sure your code does not perform any CRUD operations!! (unless of course that's intentional) The value for this fieldtype is generated at runtime and thus no data is stored in the database. This means that you cannot directly query a RuntimeMarkup field from $pages->find(). Usage and API
       
      Backend
      Enter your custom PHP snippet in the Details tab of your field (it is RECOMMENDED though that you use wireRenderFile() instead. See example below). Your code can be as simple or as complicated as you want as long as in the end you return a value that is not an array or an object or anything other than a string/integer.
       
      FieldtypeRuntimeMarkup has access to $page (the current page being edited/viewed) and $pages. 
       
      A very simple example.
      return 'Hello'; Simple example.
      return $page->title; Simple example with markup.
      return '<h2>' . $page->title . '</h2>'; Another simple example with markup.
      $out = '<h1>hello '; $out .= $page->title; $out .= '</h1>'; return $out; A more advanced example.
      $p = $pages->get('/about-us/')->child('sort=random'); return '<p>' . $p->title . '</p>'; An even more complex example.
      $str =''; if($page->name == 'about-us') { $p = $page->children->last(); $str = "<h2><a href='{$p->url}'>{$p->title}</a></h2>"; } else { $str = "<h2><a href='{$page->url}'>{$page->title}</a></h2>"; } return $str; Rather than type your code directly in the Details tab of the field, it is highly recommended that you placed all your code in an external file and call that file using the core wireRenderFile() method. Taking this approach means you will be able to edit your code in your favourite text editor. It also means you will be able to type more text without having to scroll. Editing the file is also easier than editing the field. To use this approach, simply do:
      return wireRenderFile('name-of-file');// file will be in /site/templates/ If using ProcessWire 3.x, you will need to use namespace as follows:
      return ProcessWire\wireRenderFile('name-of-file'); How to access the value of RuntimeMarkup in the frontend (our field is called 'runtime_markup')
       
      Access the field on the current page (just like any other field)
      echo $page->runtime_markup; Access the field on another page
      echo $pages->get('/about-us/')->runtime_markup; Screenshots
       
      Backend
       

       

       
      Frontend
       

×
×
  • Create New...