Add time selector to UI and allow for sending reminder on the same day as the event

[joshfeck]

Issue Overview

I would like to be able to pick the time a message goes out. Would also like the ability to remind attendees the “day of” an event. For example, emails going out at 7AM on the day of would be fantastic in our environment.

Requested here:
https://eventespresso.com/topic/configure-time-date-of-upcoming-date-reminder/

Bug report or feature request?

• Bug
• Feature
• Neither

[sethshoultes]

@nerrad is this possible? If so, how much time to implement?

[nerrad]

I would like to be able to pick the time a message goes out.

While we could add the ability to set a time for when messages are generally sent, its simply not possible for us to guarantee that's when they actually go out in a distributed plugin that could be used in a variety of hosting environments. wp-cron simply does not provide the flexibility for that kind of use-case. Any set time would generally be approximate and whether messages go out at that time or not depends on a number of variables outside of our control in the plugin.

Would also like the ability to remind attendees the “day of” an event.

So currently the ui for setting scheduling looks like this:

So that means the lowest the user can set a threshold is 1 day. We can implement the ability to choose a lower threshold but again we're limited by this being a distributed plugin and the wide variety of environments this will be in use on (similar to my explanation earlier).

In general, I can't really give a super accurate answer to your questions here Seth because there's too little information provided to do so and there's some vagueness with the request here.

• It sounds like if the first problem was solved (being able to set a specific time), the second one would be solved as well.
• Is this feature request for the ability to send the same message out at multiple times or to setup two different messages that go out at different times? If the latter, that is possible somewhat by using the Automated Upcoming Event AND Automated Upcoming Datetime templates, but whether that resolves the requirement for depends somewhat on how their events are setup as well (are there multiple datetimes?).

That's just a few questions.

The larger issue with any sort of automated reminders or outgoing messages and the scheduling, we always have to keep in mind that we are limited somewhat in how precise that scheduling can be because it depends to a large degree on the server environment the product is setup on. There's some options we have for that:

• We can design features in a plugin that have specific server environment requirements (i.e. using an actual cron job etc). This would likely be pretty non-user friendly and prone to high support volume/customer frustration.
• We can look search for and investigate third party services that might allow for doing more precise scheduling that we could integrate with using an api. If there are any out there it may be feasible to work out a partnership with them so that customers using the plugin would also subscribe to whatever service they are using.
• We build our own cloud service that offers precise scheduling for things and offer that as either a paid service or "feature" of any add-ons we release that rely on precise scheduling. This would also be useful for EventSmart needs as well. The downside to this is the bandwidth it would take way from other things while it is developed.

Going back to why I suggested doing micro automated message plugins, they were to have a very specific and targeted feature set. This means they will NOT be a solution for everyones needs. The reason I suggested we try it is because:

• there may be a subset of users for which the feature set would be sufficient for their needs and fulfill a niche that has gone unfulfilled.
• feature request could help shape an understanding of what people actually need in automated messages for an event management platform.
• we can get some real world data (through purchases of the add-on) whether there is as much demand for this as we think.

As is, while I think the add-on in its current state satisfies a specific set of needs for which it was designed - it'll never get out the door because it appears until it satisfies all the requirements of incoming shortcomings identified by users we're not going to release it? I wonder how many people are using it where it does satisfy their needs now but we just don't hear from them? I wonder how many people would use it if it was out of the pre-release channel and in production? I wonder whether there will be useful data we can act on after release that we aren't getting now because it isn't released?

Of course, I also agree we shouldn't release a product that is useless and causes more problems than it solves. I'm not sure that's been demonstrated yet.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been automatically closed because it has been stale for a significant period of time without any activity.