Regularly repeating events

The plan is to add that in using an api from event_repeat. See http://drupal.org/node/80592 for more discussion about that. I meant to start a new issue for this feature and didn't do it yet, so this will be it :-)

To remove dates, just flip the values back to blanks (for the selector) or erase them (for textfields) and they'll get deleted when you save the record. And yes, it would be nice to create a more elegant way to do that, but I haven't gotten that done. The from/to dates and repeating events features are all very new and I'm bugfixing them before adding any new features.

Actually a better link for the event_repeat discussion is http://drupal.org/node/87600.

Just wondering if you have an idea when this will be released in some form. I'm starting to play around with a site and have used eventrepeat before, but would prefer this approach if it'll be workable soon. ?

There are ongoing discussions about this, and the beginning of an idea how to get it working in the Date and Calendar modules. I'm going to do some brainstorming with others at DrupalCon. One of the big needs is to get the Event Repeat module API-enabled, which Sean Fuller is working on. I really have no idea how long it will be before all the components to do that are working.

You can manually enter repeating dates now as multiple values for a date field, there is just no automatic way to do something like 'every Tuesday and Thursday from April through June'.

subscribing

subscribing :)

Me too.

subscribing!

I will shortly begin contributing to this project and am wondering if there is somewhat of a 'master' discussion for event repeating. I seem to recall coming across one at some point, but can't seem to find it. The two links above were not what I am remembering.

Anyway, in the discussion as I recall it, there was an issue regarding the storage of recurring events. It mainly revolved around whether to make copies of the original node. In thinking about this myself, and in comparing this to evite.com and similar, I am wondering if several things can't be made to work together to minimize database bloat and maximize accuracy and efficiency.

My idea for the basics of recurring events (dates and times, really) is this:

• First, a node would be created only for the first event. If it is set to recur, the revisions checkbox should become checked and disabled for that node as the recurring part of the module will now control it.
• A column would then be added to the cck table which is tracking dates for the particular node type - or a new table created which links to the cck table- which stores future dates as 'drafts'. This new entry would only hold future dates/times for the node and would delete 'post-finalized' date/times.
• Then, either manually, or automatically at some point, the creator of the node can 'finalize' the 'draft' of the next upcoming event (and ONLY the next one; all future events remain 'drafts' until their own 'finalization').
• Changes to the individual event can be made to the 'draft' without affecting future events as all future events will have their dates based on the first version of the node. (I'm not sure whether to allow only editing the date/time in 'draft' mode, or create a temporary node revision, which allows changing of location and other details. It seems the user should be able to edit the whole node. In which case, perhaps the upcoming event could always be the latest node revision and editable (without saving even more revisions) while yet future events would be stored only as dates/times. Did I explain that so it makes sense? Also, users looking to attend the event should only be able to see the latest 'finalized' revision.)
• 'Finalization' creates a new revision of the original node. (Or, based on the parenthetical discussion above would actually finalize the one node revision and create then next in the sequence.)
• At any time, if the recurrence will fundamentally change (i.e. all future events should follow a new pattern) then the current revision will be created as a new node which becomes the HEAD of all future recurrences.
• Any emails to signed-up attendees should go out at the time of 'finalization' if there exists a module to send such emails.

I have a list of about ten different recurring algorithms to write. If no work on this has yet been done, then I volunteer to do it. However, I would like some guidance and Q&A time with either the creator/maintainer of this module or others already heavily involved as I don't want to do anything that goes counter to the current development path. And if such work has been begun, I volunteer to help and would like contact from those involved. I will need all of this done by the end of the summer and can work on it full-time.

@rconstantine

good to have someone tackling this topic. I'm no expert on this so just 2 quick comments on reading your excellent post:

1.) if possible please try to not disable revisions on repeating nodes. it's a very useful feature to let others modify content without having the original immediately wiped
2.) have a look at the Event Repeat module, I'd guess they have already thought about some of the issues ...

The discussion in #2 is the best place to go to see the ideas that are being considered for this. It's a long and convoluted thread which started out as a discussion about how to integrate Event Repeat with the Date module, and there are a number of comments from people who didn't understand that that was what the thread was about, but much of the thought that has gone into this is in there somewhere.

This much is pretty much for sure -- we will be using the re-factored Event Repeat module as an API to do the calculations and perhaps for a form to select repeat options. If we didn't do that, we would be duplicating many of the same things Event Repeat needs to do which seems silly and wasteful. Anyway, one hold up is waiting for that module to be updated, and anyone interested in this feature who wants to move things along could help out tremendously by contributing ideas, patches, reviews, etc to the API version of Event Repeat.

What's still being knocked around is the method for storing the data. That will probably either be as multiple values of the Date field for simple situations with only a few repeats, and a cached feed that can be regenerated and recached as needed or expired when no longer needed for large numbers or infinite repeats (to eliminate the need to create hundreds of table entries for every possible iteration of those dates).

I hadn't thought about using revisions for the repeats. It's an interesting thought, but I'm not sure it's the right way to go. I definitely wouldn't want any default behavior to publish or not publish future events -- that can be handled in other ways using workflow or actions, for instance. I also wouldn't want any default behavior to delete past dates -- I have many use cases where those dates are still needed.

I appreciate your offer to create this feature, but I've already spent quite a bit of time talking to people who need it, investigating options for doing this, and making sure they will integrate well into the Calendar module, and I've been contacted by several people who have clients willing to fund the development of this feature, so I planned to move forward on it myself. I'm always happy to get additional thoughts about how it could best be implemented, identify testers, lay out use cases, etc.

The discussion in #2 is the best place to go to see the ideas that are being considered for this.

I'll take a closer look.

we will be using the re-factored Event Repeat module as an API ... anyone interested in this feature who wants to move things along could help out tremendously by contributing ideas, patches, reviews, etc to the API version of Event Repeat.

Then that's where I'll begin. Hopefully, I'll be done with what I'm currently doing by early next week.

What's still being knocked around is the method for storing the data. That will probably either be as multiple values of the Date field for simple situations with only a few repeats, and a cached feed that can be regenerated and recached as needed or expired when no longer needed for large numbers or infinite repeats (to eliminate the need to create hundreds of table entries for every possible iteration of those dates).

Allow me to explain further. Both finite and infinite repeats could be handled with very little table bloat. Rather than generate a gazillion future dates, just generate the next one in the sequence. There is currently a cck table created for dates that's associated with a field name and the data in it is associated with nodes and revisions, right? That would stay the same. An additional 'draft' table, would contain ONLY the next event in the sequence. You might even be able to be clever and use just one table for both past/current and future dates. In my model, subsequent dates are always calculated from the HEAD/FIRST node revision, not the latest revision. This allows for complex repetitions like 'the 15th of every month unless it's on a weekend or holiday'. If the module does weekend/holiday avoidance, only that one revision is affected. The event after that gets its date based off of the HEAD, so it doesn't care that the one before it got moved to the 14th or 16th. I'm a little confused where you say "(to eliminate the need to create hundreds of table entries for every possible iteration of those dates)". Would you be creating as many future dates as possible right when the event is initially created? That seems wasteful, so I see why you're trying to avoid that. As I've explained, revisions would avoid this. Also, this is no worse than if a user created a new node for every event manually. In fact if there are any savings by using revisions, then you'd get that too - (do revisions in a sequence share any data with each other, or are they each full blown nodes?)

I hadn't thought about using revisions for the repeats. It's an interesting thought, but I'm not sure it's the right way to go. I definitely wouldn't want any default behavior to publish or not publish future events -- that can be handled in other ways using workflow or actions, for instance. I also wouldn't want any default behavior to delete past dates -- I have many use cases where those dates are still needed.

Auto publishing would not be a default behavior. It would be optional. As in e-vites, you can set up a future event and have it wait for you to come back and publish it, or you can set up the auto-publish. Auto-publish is usually set to some number of days/weeks/whatever before the event. I think this is very basic and doesn't need to be complicated by the necessity of other modules. I think that users who download an event repeat module will expect it to 'run by itself' and not have to do further and often complicated setup or require other modules. As for deleting dates, they would only be deleted from the 'draft' database. Each node revision would still contain the date info for itself. So for those concerned about historical data - what drupal conferences happened in 2003, for example - you'd have that.

so I planned to move forward on it myself. I'm always happy to get additional thoughts about how it could best be implemented, identify testers, lay out use cases, etc.

That's great. I guess in that case I won't get started on anything. How long do you think it will take? If you've got funding coming, does that mean you'll be able to work full-time on this?

Thanks for the response and the date and calendar modules. Another question since you brought up calendar - is anyone working on updating/replacing OG_calendar to work with you latest version of calendar? Maybe I should work on that instead? Advice?

On more thing to add:

I just came across this module: http://drupal.org/project/revision_moderation

which prevents new revisions from being published until they clear moderation. Either this very module could be used with my scheme above, or something similar.

I just read the thread you suggested. Thanks for pointing it out. I made comments there which point out that I think this idea is generally in-line with the points that seem to be agreed upon throughout the thread.

I will abandon this thread and add future comments to the other one. Thanks KarenS.

subscribing

Anyone interested in this might take a look at a core patch I submitted for 6.x to add date calculation functionality to core at http://drupal.org/node/154477. I could use that as a basis for repeating dates. It would be nice to get some additional feedback on that proposal to try to move it forward. It's pretty late in the cycle so it may not make it, but it's worth a shot. :-)

I am going to add that code into Date API for 5.x (and for 6.x if it doesn't get into core in the 6x cycle). Some sort of date calculation code is a prerequisite to getting anything done on repeating dates.

subscribe ... i'll use this on groups.drupal.org when it is born.

I'm taking a new approach to this. We're still talking about creating a central Repeat API that can be used by different modules, but it needs to work differently than the current module works. The current module does calculations by creating a huge table of possible values for dates and querying it for a match. Then, to keep it from getting too big, all entries prior to the current date are wiped out by cron. That means you can't get repeat info on past dates, plus the whole system is too cumbersome for what I wanted to do. So after a lot of research I finally realized the best solution is to migrate everything to the PHP 5.2 date functions where the date_modify() function can easily do practically everything we need for repeats.

So I'm in the final stages of a rewrite of the date module to use PHP 5.2 date functions, and when finished I think we can get repeating dates working (finally!). The new version is a complete change of the Date API, so it will be in HEAD until it is working, then it will become the 5.2 branch of the Date module (and it will be the basis for the 6.x port). All new features, like this one, will go into that branch.

And in case anyone is interested, the thread that discusses what the new API will look like is at http://groups.drupal.org/node/4979.

I'm marking this as fixed, not because it is yet working completely but because it is in development in HEAD and I need to clean out the issue queue so I can see things that have not been addressed yet.

This will still need lots of work before being ready, but the 5.2 version uses the PHP 5 date functions which can do all or most of the manipulation of dates that we'll need for repeats. This capability will live in a separate module -- Date Repeat -- so people who don't need it can leave it turned off to reduce overhead.

The HEAD version is not yet ready to use. When it is more reliable, I'll create a 5.2 branch where it will be ready for testing.

Does that mean the module is going to depend on php5?

Nope. I've created a PHP 4 emulation for the PHP 5 date functions. The PHP 4 emulation has a lot of extra code to get it working, but it is not parsed if you use PHP 5 and it will drop out once Drupal requires PHP 5. So either will work (but using native PHP 5 is recommended if you have the ability to use it).

Is there an ETA for this feature? I built a site for my church and have been calendar hopping trying to get a decent span of features. I think once we get this feature I will switch to this and be done.

This was moved to closed, but I'm getting the same problem. Date 5.x-1.8, Calendar 5.x-1.7, event-repeat 5.x-1.0. Am I missing something in where to find the fixed code?

It's not in Date 5.x-1.8, it's in the HEAD version of the Date module that will eventually become Date 5.2 (see #21). It has nothing to do with event-repeat, this is a date module feature in a new Date Repeat module in that HEAD code.

This was moved to closed because it was marked fixed previously and fixed issues are automatically closed.