After that long flurry of posts about the best way to develop this module, there does not seem to have been much activity at all of late. Are you waiting for Drupal 6? Could someone address the priorities? 5.x-3.x versus 5.x-2.x and support in Drupal 5 versus Drupal 6. Are you needing and waiting for others to help to get this done, or just busy or ...what is the plan, if you don't mind my asking?


seanbfuller’s picture

Sorry for the delay. Several things happened.

1. The project for which we were going to use eventrepeat ended up being handed off to someone else (mostly because we were just too busy to handle it). On a related note, I had a crazy summer and have not had as much time to devote to this as I'd like.

2. Killes and company have wrapped up their 5.x-2.x work and I'm planning on jumping back in. I'm close to being able to wrap up 5.x-1.1 and 5.x-2.0.

3. KarenS had to take a break from development as well. I think she's back now, but I haven't had a chance to see how things are going with calendar. I think that she has moved to requiring php5, which I'm unsure if that will work for eventrepeat, as a lot of people are still on 4. If someone could check on that, it'd be great.

At this point, I'm unsure about where the 3.x version will land.

Patches are welcome, and I will begin committing them soon. I've been trying to reacquaint myself with the code over the past week. I hope that at least give you a sense of where things are, even if the answer is not the best.

cpelham’s picture

Sean, would you care to speculate on the timeline of development of Event Repeat for Drupal 6 and whether you will be focusing on bringing 5.x-2.x or 5.x-3.x to Drupal 6 first?

cpelham’s picture

Sean, Karen says that php5 will be used if available but not required so you shouldn't have to worry about that issue.

seanbfuller’s picture

Currently, I'm questioning whether eventrepeat should be retired in favor of date and calendar. I'd like to wrap up 5.x-2.x and upgrade it to 6 just for people who need it, but generally it seems that those other two modules offer more options and better functionality. Obviously, I have not had the time to properly give to this module, and I apologize to all for this. I need to see where those modules are in development, also. Thoughts are much appreciated.

KarenS’s picture

Sean, Date Repeat was designed as an API that Event Repeat could use, if you want. It would add a dependency on the Date API but would greatly simplify your code. The API creates the selection form, which you just need to attach to the Event node in some way, and it will create an iCal RRULE string from the form results that you can store in the database. It will also do the computation of the RRULE and return you a list of dates that match that rule that you can use to create nodes. So it would cut out a lot of your code if you use it. You would mostly be left with glue code.

It comes down to whether or not you want to have a dependency on the Date API.

seanbfuller’s picture

Hey Karen,

I finally had a chance to look over the date api module and I really like the direction you're headed. I had some problems getting it working, but I think that might have to do with my running php 5.1 (I need to dig deeper and hit date's issue queue).

Could you outline the steps you see necessary for eventrepeat (or whatever it becomes) to use date api? I think just a quick bullet list of what event and eventrepeat would need to do, would help a ton in getting us to the next step.

KarenS’s picture

Sean, Sorry to be so slow responding here. The main holdup on using the Date Repeat API for Event Repeat is that the Event module is currently incompatible with the Date API (see so we have to get that fixed.

Once that is done, you can rip out all the code creating your date info table and you can rip out all code for creating the repeat selection form element -- you can add that to the Event form using something like:

$form = array(
  '#type' => 'date_repeat_rrule',
  '#repeat_collapsed' => TRUE,

And it will create a self-validating form element that will end up returning an RRULE for whatever options are selected. Then you store the RRULE in the database.

To convert the RRULE into an array of dates that fit that rule, you just do something like:

$dates = date_repeat_calc($rrule, $start, $end, $exceptions);

The $start and $end date, and the array of exceptions, need to be in the YYYY-MM-DD HH:MM:SS format, and the returned values will also be in that format. It will compute an array of dates that match the RRULE, limited to the range of the $start and $end date and with the $exceptions removed. Then you can take the array and do whatever you want with it.

The Date module implements it in CCK, so it's pretty well separated between the API and the implementation, but I haven't tried it anywhere but the Date module, so it may need a little more tweaking to be sure we've got the API completely broken out.

I've added lots of simpletests to be sure that date_repeat_calc() gets the right results from the RRULE. I set them up using examples from the ical spec to be sure it was getting the right results.

KarenS’s picture

BTW, this is working pretty well now in the 5.2 version of the Date module, if you want to see it in action. The 6.2 version is still broken, but I'm starting more work on that this week.

seanbfuller’s picture

Thanks for the heads up on that issue Karen.

seanbfuller’s picture

Looks like the issue KarenS mentioned above is now looking for people to review. People interested in leveraging date API functionality should head over there and help test:

rmiddle’s picture

Status: Active » Closed (won't fix)

5.x-3.x is dead for now. I am going to clean up 5.x-1.x and 5.x-2.x and get 6.x-1.x out the door then we can review and see where it is going.