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
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 :

  1. 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]
  2. Adding another frequency or event (currently post, daily, weekly, monthly) would also require to modify the newsletter xml files accordingly.
    Here shown in mp-content/ ! : here and here.
  3. 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 be a big modification.
  4. 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 in day d at time >= 00:00 and < 12:00, it should schedule an event for d at 00:00 .
    If the scheduler is running in 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 )

    		<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>            <!-- release the newsletter -->
    			<hour>00</hour>		<!-- [00 to 23] -->
    			<minute>00</minute>	<!-- [00 to 59] -->

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

  5. 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 recommanded 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.
  6. 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 have still this topic opened 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 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 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.


You can contact me at contribute [ at ] mailpress [ dot ] org


Related articles and links :

Date/Time component improvements in WordPress 5.3

Trac search results for wp_date

This entry was posted in News. Bookmark the permalink.