MailPress 7.2 released

- complete review of mail pluggable functions (wp_mail included + bug fixed)

- adding a List-Unsubscribe add-on trying to comply with rfc2369, rfc8058 & friends

- Newsletter schedulers & processors reviewed, use of wp_date()

- settings reviewed to comply with wp settings look and feel

- logging reviewed

- Swiftmailer 6.3.0 (with specific smtputf8 encoding support)

- Bugs fixed

- bug in csv and excel importers (when mailinglist not active)

- fixing bug in form field type

- fixing minor bug in bounce management

- several cosmetic changes (mainly code comments and css)

 

Reviewing code around newsletters

Just to post a few pictures about the last code review I made on schedulers and processors.

What is right under test for now (MailPress development version and also running on mailpress.org) is having a day scheduler and processor that would be exactly the same as the “half-day” (see previous post).

After coding, you need to make simulations to handle different cases and to have the best tests possible.

Here is my last simulation screen. The first three columns are schedulers, the first one is the results of the previous code, the second column is the results of the new code, and the third one splits the day in two (half-day). The three following columns are for processors. Not all pink are errors, just here to highlight differences.

Once the code has been tested, I set up and test it on my dev site with a new newsletter. Hereunder is a sample of a new newsletter configuration xml file. As you can see the day is divided in two.

And here are the results I checked using the standard MailPress logs. As you can see, the day is divided in two and posts are selected over a 12 hour period of time.

Newletters, Scheduling, Processing, WP 5.3 and MP 7.2

Last week, Marc had recently upgraded his site to 7.1 and asked for support because he couldn’t locate the right directory of the xml newsletter configuration files.

He was referring to an old thread on google groups.

I explained him that since 7.0 these specific files (and others) have been moved to

wp-content/uploads/mailpress/(blog_id)/advanced.

I have just upgraded the thread with that post.

He also asked if it was possible to send a category newsletter twice a day. And that was an interesting question.

I gave him my first thoughts and here is my updated analysis:

All newsletters are already scheduled twice a day, just to avoid missing any. I told him that the scheduled and rescheduled time is set upon MailPress Newsletter add-on activation time but i was wrong. The newsletter scheduling process relies on “twicedaily” wp-cron WordPress frequency that set the job at 00:00 and at 12:00. As you can see in the log below, those jobs are scheduled at 23:00 and 11:00 (not due to gmt offset but to daylight saving time [winter time in France]). At that time, I had not set the timezone settings in WordPress.

For the record, newsletter jobs as listed in wp-cron (2020/03/27) [wp-cron add-on]

Adding another frequency or event (currently post, daily, weekly, monthly) would also require modifying the newsletter xml files accordingly.

Here shown in mp-content/ ! : here and here.

Adding a new frequency would require to add the loading of the corresponding xml newsletter configuration file and would mess this admin screen

But that is not a big modification.

To add a new frequency, you have to dig in the schedulers and the processors … that could be named for the scheduler half-day and processor half-day-1.

From the beginning of Newsletter add-on, schedulers and processors are relying on their day of execution.

Here, for half-day, they have to rely on the hour of execution.

If the scheduler is running on day d at time >= 00:00 and < 12:00, it should schedule an event for d at 00:00 .

If the scheduler is running on day d at time >= 12:00 and < d+1 00:00, it should schedule an event for d at 12:00.

If the processor is running in day d at time >= 00:00 and < 12:00 it should select posts >= d-1 12:00  and < d 00:00 .

If the processor is running in day d at time >= 12:00 and < d+1 00:00 it should select posts >= d 00:00 and < d 12:00  

This is getting a little bit more complicated, when offset hours and minutes are set in the xml newsletter configuration files (see args in processor and scheduler sections )

    <processor>

        <id>day-1</id>

        <threshold>MailPress_daily</threshold><!-- stored on wordpress options table -->

        <args>            <!-- start of the day -->

            <hour>00</hour>        <!-- [00 to 23] -->

            <minute>00</minute>    <!-- [00 to 59] -->

        </args>

    </processor>

 

    <scheduler>

        <id>day</id>

        <args>            <!-- release the newsletter -->

            <hour>00</hour>        <!-- [00 to 23] -->

            <minute>00</minute>    <!-- [00 to 59] -->

        </args>

    </scheduler>

 

And even more complicated when you have to deal with daylight saving time.

For that kind of frequency (intraday), if you don't want to miss a newsletter, you have to be sure that you are not relying on genuine wp-cron as implemented in WordPress. It is wisely recommended to rely on an external scheduler. I wrote a post about this ... 9 years ago ! If you are on a single site this will still work, if you are on a multi-site, approach and code require to be reviewed.

And last but not least, a certain amount of time to code and test is also required ;-)

And ... i couldn't resist to code something ... and proposed some code to Marc.

I still have this topic open for now. As you can notice, my developments and tests were right during a specific week end : during the night between last Saturday and Sunday, I went (in France) from winter time to summer time ... daylight saving time

And my simulations and tests during that specific moment were really inconsistent!

From the beginning of the Newsletter add-on, MailPress relies on WordPress date/time functions and parameters to calculate timestamps of scheduling and processing, juggling with leap years, local, gmt and UNIX timestamps (the wp-cron standard). To be more precise, on the WordPress date function date_i18n() and get_option( 'gmt_offset' ) setting.

I just found that WordPress 5.3 has introduced a more reliable function about getting a local timestamp : wp_date() with full support for daylight saving time. So now, there is no excuse, I have to learn to juggle with daylight saving time. I still have to figure out how to get a UNIX timestamp from a local date/time 'Y-m-d H:i:s'.

Here is now my dev site settings in General Admin Settings:

To concluded this LONG post,

A) make sure that your Timezone settings are properly set in WordPress,

B) There is a complete code review of schedulers and processors to be done (any help appreciated ).

C) For now, MP 7.2 will require WP 5.4.

Implementing List-Unsubscribe and preparing 7.2

Last year, mid october, Aleksey asked for support on the unsubscribe link and related process. Rapidly, the conversation went on how to implement a List-Unsubscribe header. I quickly coded some new add-on and made some tests. But I was not particularly happy with my code and left the point for a while.

In January, I decided to re-open this topic and to see what could be done. I coded a quick and dirty hack, but then again, the process was not working as intended. Something was missing ! So I dug a little bit further trying to get more information on how to implement a nice and efficient List-Unsubcribe email header, looking for the “state of the art” in that matter.

Here are the results:

* rfc2369 - (1998/07) The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields

* rfc8058 - (2017/01) Signaling One-Click Functionality for List Email Headers

and not to forget :

* rfc2368 - (1998/07) The mailto URL scheme

* rfc6068 - (2010/10) The 'mailto' URI Scheme

To make it simple, in rfc2369, you can use the Mailto method and/or the URL method.

To avoid some automatic unsubscribing by anti-spam software, the URL method has evolved in rfc8058 adding more complexity for implementation (DKIM required). This last method is described as “1-Click RFC 8058” in the following post. Here is a little chart about how each method is supported by the major email clients…

As far as i read the documentation properly, the options are :

1) mailto method only

2) “1-Click RFC 8058” method if DKIM available (there is an add-on for that since MailPress 7.0)

In February, I started to code a new add-on called List_Unsubscribe. Today I updated the development version of MailPress in the plugin repository and added this add-on. I was willing to publish MailPress 7.2 (with that feature and other bug fixes) when WP 5.4 would be released. Due to the worldwide situation around the pandemic, and local guidelines and/or lock out, I prefer to postpone 7.2 until further notice.

It is important to focus on what really matters : our lives.

However if you have some time to test it because you are stuck at home like me, feel free to do so. The development version is available at the bottom of this page.