tony_phillips

Hi

On our site, we got Mailpoet working with Sparkpost using the Sparkpost plugin (https://www.ads-software.com/support/plugin/sparkpost). To do this we:

1. Configured the Sparkpost plugin to use the ‘HTTP API (Default)’ send method, gave it our API key, and checked the checkbox to ‘Send email using SparkPost’. (You can send a test message at the bottom of this settings page to check that this is working).

2. Configured MailPoet. On the MailPoet settings ‘Send with…’ tab, we chose to send with ‘Your own website’ and chose Delivery method ‘WP mail’ – behind the scenes this means that emails actually get sent by the SparkPost API. (You can send a test message on this page too).

3. Once we’d got this far, we found that though the emails were being sent, they were in the wrong format. This seems to be just a bug in MailPoet, which I raised on this forum in this post: https://www.ads-software.com/support/topic/integraiton-with-sparkpost-http-api?replies=3#post-8353435 – this post also shows how we fixed it ourselves on our site. Having done this, everything seems to be working fine!

This last step involves making a one-line change to a code file in the MailPoet plugin on your website. If you’re not happy or able to do this, hopefully MailPoet will resolve this issue themselves and release an updated version of their plugin which would then just work with SparkPost.

Hope this works for you.

I think this is a problem in Mailpoet and have made it work in our site using a fix I have raised with them here: https://www.ads-software.com/support/topic/integraiton-with-sparkpost-http-api?replies=3#post-8353435

I’ve recently had the same problem moving from Mandrill to Sparkpost. The Sparkpost wpmail plugin works for sending other emails from our site but MailPoet emails end up as DK describes (both HTML and plain text present but both are plain text).

Looking through the Mailpoet emailing code, I found what looks like a bug that explains this. Lines 329-330 of wp_content/plugins/wysija-newsletters/helpers/mailer.php (function wpmail_init()) look like this:

$phpmailer->Body = $this->AltBody;
$phpmailer->AltBody = $this->AltBody;

To see whether this was the problem, I changed these lines in our install to:

$phpmailer->Body = $this->Body;
$phpmailer->AltBody = $this->AltBody;

And now our Mailpoet emails work fine with the Sparkpost plugin! Mailpoet, if this is all that the problem is, is there any chance you could fix it? Many thanks.

Hi Bev

Sorry for the delay in getting back to you and thanks again for the brilliant speedy response. I’ve installed version 2.1.0 on our development site and our monthly events are appearing correctly now. So as far as we’re concerned in practice, that’s our issue resolved. So many, many thanks!

However, I feel I should mention that I think that both the issues ((1) events not appearing if they don’t recur up to the end of the upcoming dates shown; and (2) if that were fixed then events being shown beyond their final recurrence) will still be present for annual events, as the code for annual events is not consistent with the code for the other frequencies. Specifically:

1. For issue 1, I think the second comparison with $date2 in the SQL on line 1362 should surely be with $date1 (like it is for the other recurrence frequencies). As it is, this SQL is only going to find annual events that repeat right up to the year of the end of the upcoming event range.

2. For issue (2), if I change the SQL code on line 1362 as described above, then I think it is working correctly for annual events that span the year-end (as the filter_events() code for this case on lines 1417-1433 includes the necessary tests), but not if the event doesn’t span the year-end (as the required code isn’t there in the lines 1411-1415).

I think issue 2 will only ever be observable on sites where the calendar is set to show upcoming events for a large number of future days (more than 1 full year). Issue 1, on the other hand, can be replicated more easily (I created a ‘New Year’ event for 31-Dec-2014 with 1 annual repeat, and the recurrence for 31-Dec-2015 didn’t show up on our event list – but with the SQL changed as described above it did appear).

I hope that my raising this annual issue is useful (rather than just annoying), and thanks once again for dealing so brilliantly with our actual problem. When I have a moment I’ll put a 5* review for the great plugin and awesome support.

with kind regards

Tony

Dear Bev

Many thanks for the fabulously quick response. I have tried the new version on a development version of our site, and it is certainly working better but there is still one outstanding problem that I raised above (sorry if I didn’t explain this clearly enough initially).

The development version resolves both problems 1. and 2. in my report above, but the problem raised in the paragraph after those is now occurring. Here is an example that shows the problem:

In our test site, I have set up 3 monthly (day) recurring events in a specific category. These are:

1. An event starting on 2015-09-13 that repeats 3 times (occurs on 2015-09-13, 2015-10-11, 2015-11-08 and 2015-12-13).
2. An event starting on 2015-09-27 that repeats 2 times (occurs on 2015-09-27, 2015-10-25 and 2015-11-22).
3. An event starting on 2016-01-03 that repeats 1 time (occurs on 2016-01-03 and 2016-02-07.

In the upcoming events list for that category and the calendar set to show dates up to 90 days into the future, the new version shows the following dates:

October 11, 2015
October 25, 2015
November 8, 2015
November 22, 2015
December 13, 2015
December 27, 2015 ** this repetition of event 2 should not be here **
January 3, 2016

Changing the setting to display upcoming events further into the future confirms that it continues to show the events as recurring beyond their specified number of repeats.

This behaviour looks consistent with the code that handles monthly repeating events in filter_events(), which doesn’t have any code to make sure the date is not after the final recurrence of the event (though some (but not all) of the code for yearly repeats, and the code for weekly and daily repeats, does look like it checks this – see for example line 1495-1496 for weekly repeating events).

Once again thank you for your speedy help with the first two problems; I hope this other problem is easy to deal with too.

Many thanks
Tony