|
December 20, 2022 at 7:27 am
Hi there,
So I’ll address your question related to the code first:
When the date function is called, it converts the UTC GMT time back to local time, but event start datetimes are stroed in UTC in the database…
No, it wouldn’t cause the query to ‘miss’ events, what it could do is shift the time for that query but they still wouldn’t be missed. As long as the above conversion happens with every query it will shift the times in which the query would pull the events in but still trigger for them.
Here is getStartTimeForQuery():
return time();
Now, getEndTimeForQuery():
return $this->getStartTimeForQuery()
+ (DAY_IN_SECONDS * $settings->currentThreshold($context))
+ $this->cron_frequency_buffer;
So that’s basically saying the current time + X days (set in the template) + cron_buffer
The buffer for upcoming queries is set to use a default of ‘Every 3 hours’, then we add on 30mins to that just in case someone has changed the above to be 0 (its filtered) and we need a value.
So for the above the start value output by date would be something like:
2022-12-20 14:04:51
End:
2022-12-21 17:34:51
(That is with a threshold of 1 day and default buffer)
We use the buffer because we can’t rely on WP_CRON to be consistent enough to say for sure it will trigger the messages on the day it should, so we extend the query to allow for that. However, your setup with using an actual cron removes that inconsistency, it runs every 15 mins so even with the conversion the query would run and trigger the notifications.
Now I’ll move on to your other questions:
What happens when a transaction contains multiple registrations to multiple events on different days and times? Will each registration generate an upcoming reminder email, or only for the first event in that list of registrations?
Which message type are you using for these?
The upcoming Event notification will trigger emails for the first DateTime in an event only.
The upcoming Datetime notification triggers registrations for each Datetime.
The query looks for registrations related to either the Event or Datetimes, it does not care about group registrations etc. It pulls in the registrations related to events based on the first DateTimes start date.
The Datetime notification pulls in all the datetimes based on the start date and loops over each of those DateTimes to trigger notifications linked to those DateTimes, again it’s not looking for registrations in groups etc, it just pulls in the registrations related to the current DateTime using the DTT_ID value.
For each of those, it then sets an extra meta value in the Database to say that the Upcoming notifications have been process for it and the query then skips those next time.
If we set “Generate and send all messages:” to “On the same request”, will the automated upcoming event notification plugin still work? I’m guessing it won’t?
No, the AUEN notifications will not work without that option, but I don’t think changing that setting is going to fix anything here either way.
So yes, the inefficient way cron is run via WordPress is disabled, but we run it manually every 15 minutes. It appears to me this should work, as there’s a 30 minute flex window for the queue generation of messages for upcoming?
Using a real cron is absolutely fine, we can’t rely on it because many people can’t/won’t set them up which is why we use WP_CRON and advanced users can option to do the above.
|
