Relative dates for scheduling and registration reminders

I'm also surprised this isn't available. How are other sites handling this? With all the Drupal sites using Entity Registrations, surely some others must have needed reminders x hours/days before each event.

Anyone working on this? I'm happy to help test if there's something started...

registration_date allows you to use an offset or a specific date.

@SocialNicheGuru: Registration Date allows you to use offsets to open and close registrations. This is about using offsets to send reminder emails (not close registrations).

@kclarkson: Agreed, although I'm not necessarily opposed to an add-on module if the maintainer doesn't want to support this in the primary module.

I only proposed it to show a module that does deal with scheduling. This might be adapted to send reminders.

It would also be useful to set a send date relative to "now" (the moment of registration completion). Like "now +10 minutes" or "now +1 day" etc.

s

Hey guys - I really want to use this module for our new registration system but this relative date this is a big hesitation. As people have said, we desperately need a relative dates for reminders. In fact I would love to see a default "feedback" email option for after the event as well. I haven't done much exploring yet, but can we at least try to strongarm the default reminders via rules?

Yes please.

Created a patch to reference a date field on the field settings form.

Date popup functionality invalidates the strtotime settings, so I removed it from the reminder date field.

This is great! I'll try to review this soon, because I think this is a feature that would be really useful to have.

If you add a new parameter to a function make sure to change all instances of the functions in the module. There's another call to "registration_update_entity_settings" in "function registration_entity_settings_form_submit" that should be tested.

function registration_entity_settings_form_submit($form, &$form_state) {
  $entity = $form_state['entity'];

  $fields = registration_convert_form_settings($form_state['values']);

  registration_update_entity_settings($entity['entity_type'], $entity['entity_id'], $fields);

  $uri = entity_uri($entity['entity_type'], entity_load_single($entity['entity_type'], $entity['entity_id']));

  $form_state['redirect'] = $uri['path'];
}

Also, it's good to add some help text to
$form['default_registration_settings']['reminder']['reminder_settings']['reminder_date_field']

And there are a few introduced code errors.

  FILE: registration/includes/registration.field.inc
--------------------------------------------------------------------------------
  86 | ERROR | There should be no white space after an opening "("
  86 | ERROR | TRUE, FALSE and NULL must be uppercase; expected "NULL" but
     |       | found "null"
  94 | ERROR | Line indented incorrectly; expected 8 spaces, found 7

  FILE: /home/maria/checkouts/registration/includes/registration.forms.inc
--------------------------------------------------------------------------------
  697 | ERROR | Missing comment for param "$entity" at position 2

#15 works well for me, with the exception of altering registration_entity_settings_form_submit() to include $entity passed to registration_convert_form_settings() as noted above. That works.

Also: Is there any reason why all the times are specified with seconds? (H:i:s) throughout the module? That seems unnecessary, and it looks kind of confusing for users used to entering times like "12:30".

kclarkson, did you make sure to update the other function as well?

I agree thought hat ideally there would be a dropdown box like in the Signup module with a choice of "1 day" "48 hours" "72 hours" and "1 week" or something. Users don't really get having to put in a fully-formatted time.

I too am struggling to follow along, a revised patch would be a big help. Thanks

would be great to have a working patch.
Thanks

Any movement on this? A straightforward way to configure the reminders based on relative dates would be excellent for this module.

This can be easily done with the hooks proposed to the maintener. With these hook you can update registration settings width all the data available in the entity host. You have to implement this hook in a custom module, so it's not so user-friendly than patch #15 but you can do everything you need (altering open, close date, reminder date, capacity, etc.)

See this issue Provide hook allowing other modules to alter registration settings when an entity host is created or updated

One issue here is that Registration can't reliably know about the date field used by the host entity.

I've only taken a quick look at your suggested additional hook, @flocondetoile , but in the meantime I achieved a relative Reminder Date value per below.

It seems to me that we don't want to set a Reminder Date value unless Send Reminder is checked (I've been thinking about this in #2431621: Allow Reminder settings without Send Reminder box checked for field defaults, but not on host entity), so my approach is to populate the Reminder Date value with a default when the Send Reminder box is checked.

First, in my module I use this in a form alter:

    // Populate the Reminder Date field with a date relative to the event.
    if(empty($form['reminder']['reminder_settings']['reminder_date']['#default_value'])) {
      $host_entity = node_load($form_state['entity']['entity_id']);
      $host_entity_wrapper = entity_metadata_wrapper('node', $host_entity);
      // The date from the entity host is a datetime field, formatted
      // 2015-02-28 21:02:00
      $event_date_formatted = $host_entity_wrapper->MY_DATE_FIELD->value();
      // Convert to Unix time, and be sure to account for the field's timezone
      // settings: the registration date field uses the site's timezone.
      $event_date_u = strtotime($event_date_formatted['value'].' '.$event_date_formatted['timezone_db']);

      // The reminder date we want is two days before the entity host date.
      $event_date_u -= 3600 * 24 * 2;

      // With the date_popup module, our registration date field wants to be
      // formatted: (date) 03/21/2015 (time) 01:35pm
      $reminder_date = date("m/d/Y", $event_date_u);
      $reminder_time = date("h:ia", $event_date_u);

      // Add our JS and pass the variables to it.
      drupal_add_js(drupal_get_path('module', 'MYMODULE') . '/MYMODULE.js');
      drupal_add_js(array('MYMODULE' => array('reminderDate' => $reminder_date, 'reminderTime' => $reminder_time)), array('type' => 'setting'));
      // Debugging: set field values directly, w/o waiting for JS event:
      //$form['reminder']['reminder_settings']['reminder_date']['#value']['date'] = $reminder_date;
      //$form['reminder']['reminder_settings']['reminder_date']['#value']['time'] = $reminder_time;
    }

Then, MYMODULE.js looks like this:

/**
 * When Registration Send Reminder box is checked, update Reminder Date with a
 * default value based on the host entity event date.
 * This will only fire if the Reminder Date is empty when the Registration form
 * is loaded.
 */
(function ($) {
  Drupal.behaviors.MYMODULE = {
    attach: function (context, settings) {
      $('#edit-reminder-send-reminder').click(function() {
        if ($(this).is(':checked')) {
          $('#edit-reminder-reminder-settings-reminder-date-datepicker-popup-0').val(Drupal.settings.MYMODULE.reminderDate);
          $('#edit-reminder-reminder-settings-reminder-date-timeEntry-popup-1').val(Drupal.settings.MYMODULE.reminderTime);
        }
      });
    }
  };
})(jQuery);

@arh1 Unfortunately, the relative date is still needed globally because those settings can be set as default on the registration type. In our application we need those to be inherited by default when you create a new registration node.

Your solution is great, but it means manually editing every node we create after the fact to set the reminder date and that doesn't change anything about how the process currently functions.

I'm looking into how the signup module accomplishes this and might have a solution hopefully soon.

Thanks, @oranges13. Just to clarify, to help move the conversation along...

@arh1 Unfortunately, the relative date is still needed globally because those settings can be set as default on the registration type.

Yeah, a specific/absolute date as a default Reminder Date value on the registration field doesn't make much sense to me. (I'm doing some thinking about that over in #2431621: Allow Reminder settings without Send Reminder box checked for field defaults, but not on host entity.)

A relative date makes sense in principle there, but what is it relative to? In the Registration field we'd need to point the Registration to the appropriate "event date" field on the host entity (and then do the calculation, validation, etc on the host entity Registration settings form).

In our application we need those to be inherited by default when you create a new registration node.

Your solution is great, but it means manually editing every node we create after the fact to set the reminder date and that doesn't change anything about how the process currently functions.

You're right that my approach does require clicking the Send Reminder box on the host entity. It just automatically gives you a reasonable Reminder Date value based on the "event date" when you do so. (In my case, we don't always want reminders enabled so this makes sense.)

This is admittedly not the right solution to addressing this w/in Entity Registration, but can provide a viable workaround in the meantime.

A relative date makes sense in principle there, but what is it relative to? In the Registration field we'd need to point the Registration to the appropriate "event date" field on the host entity (and then do the calculation, validation, etc on the host entity Registration settings form).

If you look at the submitted patches so far, that is what is occurring here.

Basically, instead of taking a date entered into the reminder date field at face value (such as "February 6 at 2pm"), this patch allows you to associate a date or datetime field that is part of the host entity, and use a default offset (such as "-2 days") to that value on a per-node basis. When the entity is created, this calculates the actual reminder date based off the entity's date field and the reminder offset entered in the default settings.

Your discussion on the other issue is still relevant, because you might want the settings set up, but not want that box checked on every instance.

I am SO CLOSE to getting this working! I should have a patch shortly, and you should be able to see what I mean :)

Okay! Here is a cumulative patch with the previous errors from #17 fixed and a few other changes. Here's how it works so you can test it yourself!

Most Importantly: This was rolled against the 7.x-1.x dev branch

This patch will allow you to set a relative date (such as -2 days or +3 days) on the default registration field settings by selecting a related date field to apply the offset. Once an actual entity that utilizes that field has been created, it will set an actual date value using the related date field and the given offset.

For example:

• On the default settings, I enter -2 days in the Reminder Date field and choose to relate it with an event_date field in the host entity.
• When I create an Event, I choose "February 6, 2015" as my event_date value.
• When this event is saved it will use the event_date value and the reminder_date value of -2 days to set the reminder_date to "February 4, 2015".
• This date can then be edited on a per-node basis to a specific date

Another example:

• On the default settings I enter a date, "February 8, 2015"
• I do not choose a related field
• When an event is created, ALL subsequent events using this registration field will have their reminder dates set to "February 8, 2015" by default, but can be edited individually after creation.
• This is the current functionality that the module supports.

@nielsonm removed the datepicker on the default settings form, but I have restored it to the entity-specific-settings form since it makes choosing reminder dates manually much easier.

A huge shoutout to @nielsonm for most of the work on this, I just tweaked it a bit, added help and made sure it was completely working against the new -dev version. Please let me know if this works for you!

+1 for committing this, I've tested it on the latest dev and it works great. Thanks so much all!

Can we get this in the next release?

The patch in #30 no longer applies to the latest dev.

Rerolled the patch against latest 7.x-1.x branch!

Please let me know if you have any questions or concerns :)

The patch applies nicely. In general it works, but I'm having an issue with the time zone offsets.

On my event content type, I have a Date field with the timezone settings set to Site's time zone (which is America/Los Angeles). I used the relative reminder settings and input a date offset of -4 days (as an example). I created an event at 2 pm (14:00 in 24-hour time). When I checked the registration settings, the reminder email was set to be sent 4 days earlier, but at 21:00. This is 7 hours after the event start time - equal to the current UTC offset of America/Los Angeles.

Hello! This should squash that bug! Please test, thank you!

Looks good!

The timezone offset issue is fixed. I am seeing some PHP notices on the registration field settings page on my content type:

Notice: Undefined index: reminder_date_field in registration_field_instance_settings_form() (line 124 of /test-registration/sites/all/modules/contrib/registration/includes/registration.field.inc).

The notice appears when I first load the settings page (before I've chosen a date field) and also on the Manage Fields page the first time I load it. It goes away after I've saved the settings (specifying a date field) and reloaded the page.

I have a few more patches applied, so the line number of the error above doesn't match what you'd get with only the current dev version plus this patch. It should be line 130 in that case. Here's the code where the error occurs:

  $form['default_registration_settings']['reminder']['reminder_settings']['reminder_date_field'] = array(
    '#type' => "select",
    '#title' => "Date field to use for Reminder Offset",
    '#options' => $options,
    '#default_value' => $default_settings['reminder_date_field'],
    '#description' => t('Choose a date field that will be used along with an offset in the reminder date field to automatically set the reminder date by default.'),
    '#weight' => -1,
  );

The error is on the line that sets the default value based on the default settings.

Is it possible that you could elaborate on the other patches you have applied?

I just tested with a new install of Drupal (with devel, date, and registrations enabled) and the notice did not appear. This is with the dev version as of July 17 plus my latest patch.

I even tried it without the date module enabled. The notice does not appear for me, and using dpm() to display the $default_settings array in question shows that the index does exist so the notice shouldn't be occuring unless one of the other changes is unsetting it somewhere.

I also just confirmed the notice does not appear on simplytest.me either.

https://dzxz.ply.st/ <- has this patch + registrations enabled with a basic content type

This is a great feature but I'm not thrilled with the implementation: having settings that are different between the field instance defaults and the actual configuration of settings on an entity is opaque and confusing.

Those options should be outside the "Default Registration Settings" and just be instance-level configuration. Also, we should elegantly handle anyone updating to a version with this feature: currently I get a notice "Undefined index: reminder_date_field" when I load the field instance configuration on an existing registration field after applying this patch.

I'm going to mark it as "needs work". I'd love to offer this feature if we can get a revised implementation!

this is really pitty that for so many years this module is lacking so basic feature as sending email reminder 1 day before (or x day before) start.
Module Signup had simply settings - text box when you could wrote number for how many days before start of the event was reminder sent.

In this module probably nex few years yet authors/developers will be thinking about yet more mega giga complex solution for this simply thing, and after then ther will be nobody use Drupal and these modules, exactly because this behaviour/thinking of module authors.

igorik, I planned on patching this against the 7.x-2.x branch of this module and would like to invite you to think along with my planned approach here: #2629758: Allow relative dates for scheduling and registration reminders. Since the module is open source, nobody is preventing you to think and code along.

Speaking bad about the maintainers is not going to help anybody I'm afraid.

Igorik - if you use the patches included in this issue, you will see the feature does exist, it's just not been rolled up into a released version yet.

Neograph734 is there a reason these patches are no longer useful and you had to create a new issue? :(

Because most work is bow being done in the 7.X-2.X branch I felt it would make sense to take this feature there and hopefully have it rolled in there.

Since the maintainers say this needs work, working together with them in the active branch should lead to more feedback and a patch that should apply better. I certainly don't want to imply the work is is useless and done for nothing.

Neograph, I think the issues were more about how it was implemented rather than actual problems with the conceptual work - as you've seen because the registration itself doesn't actually have a date associated with it, it gets kinda tricky.

I know that gcb said he didn't like the way it was implemented, but the ability to set default which are then inherited by each new registration when created are somewhat important. One of the things I wanted to avoid was editors having to re-enter settings every time you create a registration entity. So we're just not seeing eye to eye on that I guess.

If they have the fundamental differences between 1.x and 2.x somewhere, we can work together to see how much of this could be reused.

It's great to see the dialog on this patch move forward. Just to confirm what Neograph is writing, our active development is in the 2x branch of Registration. 2x is as good as 1x, but it has additional features that allow you to register any type of entity while 1x only allows you to register users. This feature improves registration's usefulness and integration with other modules.

@oranges13, I totally agree with you that there should be some global setting on the field that can be overridden with a per-instance configuration. I however also think we should implement relative dates for open and close dates as well as registrations, so we can, for example, by default close a registration 1 day ahead.

The way I thought about implementing it was by having 2 radio buttons per date field, allowing one to choose between relative or absolute date, then during the save, rewrite everything into the existing absolute date field, so everything will remain functioning as it does. We can toggle the different inputs with AJAX (form states API to be exact) and both values can co-exist always rewriting back into the absolute date.
Also the current patch seems to be able to only inherit a date field from the node (line 24 of the patch), while a registration can exist on any entity so some more work is required there as well. But I like the work being done there to select the field.

Finally I'd like to invite you all to continue this discussion in the other issue #2629758: Allow relative dates for scheduling and registration reminders, as it is more relevant because of the active branch as Greg pointed out, even though the branches might not differ that much.

I don't know better then to create a new issue for a new branch, but apologies for any confusion. Switching the version as you did should work as well.

I'd like to get some feedback on the patch (is the UI clear, is the approach ok, etc) and still need to fix two outstanding issues:

Some validations that need updating (such as the registration requires a date check).
Also if no field is provided, it should not be an option to select it and minor ui tweaks (such as field descriptions).

I can work on this further next week, so it would be really helpful if I could get some insights by then.

Oke, I've reworked some bits of the old patch. I felt that it did not make much sense to store the event date in the registration table as some registrations might not require this and it would result in duplicate date in eg. Views, etc.

So... This patch allows one to select a date field during the creation of the registration instance on the entity, this date field will then be used as base for relative dates. (If omitted the module will function as it does now.)
If a relative date field is chosen, the relative options will become available on each individual entity's registration settings (inheriting the default relative options from the field instance).

The registration core is unchanged so all relative fields are rewritten to the existing open, close and reminder date fields during the saving of the registration (so other aspects of the module such as cron remained untouched). If the parent entity is updated and the date field has changed, the registration settings will be recalculated and saved again. So if you move the event a day, all relative dates will shift one day as well.

Guys, this took me quite some time (although part of the field detection logic is done by oranges13), but I feel this is the most elegant way to handle this. Please let me know what you think!

A notice for those who tried the previous version. The database update hook has been removed again and the extra 'event_date' column has been removed from the 'entity_registration' table again. You should set reinstall the module (preferred), or manually remove the 'event_date' column and set the schema version back to 7201 in the 'system' table in order to prevent collisions with next updates.

I tried the patch, UX looks very good, chosing date field is excelent solution, thanks!

Just an question, because it is not obvious for me, the scheduling fields (start, close) are doing what?
There is no explanation so I have no idea.

Big thanks for your work!
Igor

Thanks for the feedback, glad you like it!

The regular module uses 3 date field (the absolute dates). One on which to open the registration, one on which to close the registration and a date for sending reminders.

The proposed patch tried to replicate this by allowing relative dates for all field. So open offset could be to open the registration 10 days before the event (-10 days). Close offset could be 12 hours before the event (-12 hours). And the reminder is when to set the reminder. I will update the descriptions in the patch when I have some spare time.

Does that answer your question?

yes, now I understand it completely, Scheduling fieldset is for open and close registrations on the event.
Maybe just an idea for default value/behaviour of it when user doesn't need to change this - open registration date could be on the date when event was created and closing date will be date of the event.

If you leave the values empty, they will not do anything (registration can be opened or closed with the 'Active' checkbox on top instead). But I will add some descriptions. Thanks for checking this out.

Here you go. Hope this is better to understand.

I couldn't get the patch to apply to the 7.x-2.x-dev (Feb 24, 2016). I went into the sites/all/module/registration folder and tried to apply the patch from there.

curl https://www.drupal.org/files/issues/relative_dates-1559178-61.patch | patch -p1
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 30056  100 30056    0     0  74824      0 --:--:-- --:--:-- --:--:--  167k
(Stripping trailing CRs from patch.)
can't find file to patch at input line 8
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: includes/registration.field.inc
|IDEA additional info:
|Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
|<+>UTF-8
|===================================================================
|--- includes/registration.field.inc    (revision 99dd0c545727912c9892bd86d224979d67e0a360)
|+++ includes/registration.field.inc    (revision 110254e979fb72bd34aaee72eae51284d754e002)
--------------------------
File to patch: includes/registration.field.inc
patching file includes/registration.field.inc
Hunk #2 FAILED at 91.
Hunk #3 succeeded at 333 (offset -23 lines).
Hunk #4 succeeded at 372 (offset -23 lines).
1 out of 4 hunks FAILED -- saving rejects to file includes/registration.field.inc.rej
(Stripping trailing CRs from patch.)
can't find file to patch at input line 130
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: registration.module
|IDEA additional info:
|Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
|<+>UTF-8
|===================================================================
|--- registration.module        (revision 99dd0c545727912c9892bd86d224979d67e0a360)
|+++ registration.module        (revision 110254e979fb72bd34aaee72eae51284d754e002)
--------------------------
File to patch: registration.module
patching file registration.module
Hunk #1 succeeded at 819 (offset -43 lines).
Hunk #2 succeeded at 839 (offset -43 lines).
(Stripping trailing CRs from patch.)
can't find file to patch at input line 212
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: includes/registration.forms.inc
|IDEA additional info:
|Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
|<+>UTF-8
|===================================================================
|--- includes/registration.forms.inc    (revision 99dd0c545727912c9892bd86d224979d67e0a360)
|+++ includes/registration.forms.inc    (revision 20fdc5284fc6c2adf7f73135452385128c1d14f1)
--------------------------
File to patch: includes/registration.forms.inc
patching file includes/registration.forms.inc
Hunk #1 FAILED at 518.
Hunk #2 succeeded at 473 (offset -65 lines).
Hunk #3 succeeded at 496 (offset -65 lines).
Hunk #4 succeeded at 507 with fuzz 1 (offset -65 lines).
Hunk #5 succeeded at 551 (offset -65 lines).
Hunk #6 succeeded at 566 (offset -66 lines).
Hunk #7 FAILED at 659.
Hunk #8 succeeded at 622 (offset -67 lines).
Hunk #9 succeeded at 673 (offset -67 lines).
Hunk #10 succeeded at 803 (offset -90 lines).
Hunk #11 FAILED at 925.
Hunk #12 succeeded at 861 (offset -90 lines).
Hunk #13 succeeded at 877 (offset -90 lines).
Hunk #14 FAILED at 987.
4 out of 14 hunks FAILED -- saving rejects to file includes/registration.forms.inc.rej

I am unfortunately aware of that, but due to lack of maintainer response I don't feel the motivation to work on this anymore. See: https://www.drupal.org/node/2543090#comment-10763198.

You are free to take the patch and rework it so that it applies again.

@rwilson0429 I think that Neograph patch was done for 1.x version.
2 months ago I tried it for 1.x version and it worked nice.

It was for 2.X, but might still apply to 1.x

Thank you Neograph734 for your reply and your extensive work on this functionality. It seems that this project is very actively maintained. So, I hope that one of the maintainers will respond to your patch once it has been reviewed and the status is changed to RTBC.

I, and I'm sure many others who will be looking for this functionality, do appreciate and value your contribution to this issue. So, I hope that will be motivation enough for you to continue to help get this functionality committed.

igorik, thanks for the tip to use the 1.x version. I'll give that a try.

Circling back to this patch: It still applies as of version 7.x-1.6, with a bunch of offset code chunks. (I haven't looked at version 2.x yet.) However, you have to apply it using -p0 instead of the usual -p1.

The basics look sound, but I'm seeing a problem in the initial save. When I first create an event with a registration field, registration_entity_update_relative_dates is not able to find the value of the specified date field. Relative dates are being calculated based on the Unix epoch instead. If I immediately edit the event and save it again, the date field value is found and the relative date is correctly calculated.

The root of the problem is that if you have the Enable registration box checked in your default settings, there is no source for the event date value in the function registration_convert_form_settings. The event date is only set as part of the registration form. If you enable registration by default, all of the settings functions run in the absence of that form when you create a new entity. There needs to be some way to get the event date without relying on the registration form being active at the time.

@cboyden The original approach to this issue was to take a known field on the content type and assume that would have the date, and then apply relative adjustment once the node content had been saved. We completely solved this issue but the module maintainer said they didn't like the approach, though I don't know how else to go about it.

@oranges13 I'm just evaluating the patch as-is, and I discovered a case that it doesn't cover. I may choose to use something like this in my own makefile, so I'd like to address that case here and clean up the patch. I'm not sure about the implications of @gcb's question above. The only thing that's different between the default field config and what you can configure for each instance of a register-able entity is that on the default field config, you choose the date field.

The patch on #61 applies with some offset to 1.6, but I get some fatal errors:

1. +++ includes/registration.forms.inc	(revision 20fdc5284fc6c2adf7f73135452385128c1d14f1)
   @@ -807,23 +966,53 @@
   -  if (!empty($reminder['reminder_settings']['reminder_date'])
   +  if (!empty($reminder['reminder_settings']['reminder_date'] && $reminder['reminder_settings']['reminder_type'] == 'absolute')
   

   There's a syntax error here - no closing parenthesis for empty() and extra parenthesis after the 2nd expression.

2. +++ includes/registration.forms.inc	(revision 20fdc5284fc6c2adf7f73135452385128c1d14f1)
   @@ -807,23 +966,53 @@
   +  if (!empty($reminder['reminder_settings']['reminder_relative'] && $reminder['reminder_settings']['reminder_type'] == 'relative')
   +    && strtotime($reminder['reminder_settings']['reminder_relative']) === FALSE) {
   

   Similar issue here

I've attached a new patch that fixes these.

Sorry, I messed up that last patch. The interdiff was correct, though!

I've re-rolled the patch to apply to 7.x-1.x. There's some conflicts when going to 7.x-2.x, but that'll probably need to be resolved before this can be committed.

Here's a version of the patch that fixes the problem identified by @cboyden in #67 and #68. It's kind of messy in that we're setting the default settings in hook_entity_insert() and then immediately loading the settings - this could probably be refactored to be cleaner.

Also, I'm seeing this PHP warning - but it isn't preventing it from working:

Warning: strtotime() expects parameter 2 to be long, string given in registration_convert_relative_date() (line 1042 of registration/includes/registration.forms.inc).

Thanks @dsnopek! I think if we move the added code further down in the stack, it will prevent the error because we will have found the correct date to base the relative calculation on before the settings are saved for the first time. I'll take a crack at that.

I've updated the patch so it doesn't cause a PHP warning. The patch includes a new helper function to get the event date for use in updates/comparisons.

I was not able to figure out how to get this working without essentially saving the settings twice in the registration_entity_insert function.

Here's a new version that avoids saving the settings twice!

It also removes a type hint for 'reference' that was causing a PHP fatal error under PHP 5.3 (not sure if that's supported on newer PHP) and it cleans up the return value of the new registration_get_base_entity_date() function.

The new patch looks great. Works fine in initial testing.

The previous patch had an issue: if you create an event with registration disabled, then edit the event and enable registration, it won't correctly setup the relative dates. Here's an updated patch that fixes this issue in my testing!

#81 works fine for me.

Thanks, dsnopek! Patch works perfectly. Can we mark this as reviewed?
And how we can bring developers attention to issues like this? There are several much needed patches in this issue queue.

RTBC'ed based on #82 and #83.

There is a small annoying issue with #81. The date and time of absolute date must be filled in, otherwise you get a complaint that the date needs to be in the future when saving. Even if relative date is selected.

Edit: The easiest fix for this is to comment out the error message in includes/registration.forms.inc,
form_set_error('reminder][reminder_settings][reminder_relative', t('Reminder must be in the future.'));
also useful if you want to allow relative dates in the past if automatically setting relative dates.

doesn't apply cleanly to dev (7/12/2016)

patch -p1 < registration-relative-dates-1559178-81.patch
patching file includes/registration.field.inc
Hunk #1 FAILED at 18.
Hunk #2 succeeded at 85 (offset 3 lines).
Hunk #3 succeeded at 381 (offset 3 lines).
Hunk #4 succeeded at 421 (offset 3 lines).
1 out of 4 hunks FAILED -- saving rejects to file includes/registration.field.inc.rej
patching file includes/registration.forms.inc
Hunk #1 succeeded at 519 (offset 33 lines).
Hunk #2 succeeded at 572 (offset 33 lines).
Hunk #3 succeeded at 596 (offset 33 lines).
Hunk #4 FAILED at 574.
Hunk #5 FAILED at 584.
Hunk #6 succeeded at 626 (offset 32 lines).
Hunk #7 FAILED at 622.
Hunk #8 succeeded at 743 (offset 91 lines).
Hunk #9 succeeded at 794 with fuzz 2 (offset 90 lines).
Hunk #10 succeeded at 947 (offset 112 lines).
Hunk #11 succeeded at 979 (offset 112 lines).
Hunk #12 succeeded at 1035 (offset 112 lines).
Hunk #13 succeeded at 1051 (offset 112 lines).
Hunk #14 FAILED at 959.
4 out of 14 hunks FAILED -- saving rejects to file includes/registration.forms.inc.rej
patching file registration.module
Hunk #1 succeeded at 817 (offset 13 lines).
Hunk #2 FAILED at 823.
Hunk #3 succeeded at 1107 (offset 7 lines).
1 out of 3 hunks FAILED -- saving rejects to file registration.module.rej

this is really pity it is not yet integrated to the module (maybe as a submodule).
It is 5 years!!! from the intial issue.

#81 works fine for me.

This is supported by the registration_scheduled_action submodule in version 3.x