Monthly repeat pattern produces multiple events in Upcoming Events block list

we are having the same issues, but it is not just with monthly events, it seems to be all re-curring events. we didn't catch this for awhile and now we have thousands of duplicated events and are struggling to try to find a way to delete them all.

We had(ve) the same problem - we started trying to delete them by hand but it was really slow. What we did we via a SQL script in PHPMYAdmin we set all the nodes that we didn't want as unpublished. We then created a cron job to select and delete the offending nodes. It still took a long time to run but at least it automated the process.

I'm hoping to carve out some time today and look into these issues. Let me know if you find out anything else.

Thanks for the bug report.

skierboy and marcingy, what is the base node type you are using to create events? Flexinode? Basic event? CCK?

Also, what are you repeat end options set to on these? Are they also undefined like Rainy Day's?

I'm trying to test this with flexinode and cck now, but it will probably be at least tomorrow before I would really see the issue.

Sounds like it's not cron, so I'm wondering if the update api is getting called when it should not.

They are basic events. The events have a mixture of rules. Some have no end date and are repeating, while others have an end date. Both are weekly and have a day set for reoccurence.

Thanks

I'm still having a hard time reproducing this with my test site. Any other details would be appreciated to try and find the common element that could be the culprit. Given the severity of this problem, it is currently holding up the release of the new 4.7 version of this module.

I'm still unable to duplicate this one, but I was looking through the code today and found this in eventrepeat_nodeapi:

    case 'load':

      if (variable_get('event_nodeapi_'. $node->type, 'never') != 'never') {

        //if the old start time hasn't been saved to the update code yet, then save it.  this is a total hack,
        //but i don't know any other way to do it
        if (!$old_times && $_POST['op'] == t('Submit')) {
          $old_times = db_query('SELECT e.event_start, e.event_end, timezone FROM {event} e WHERE e.nid = %d', $node->nid);
          if (db_num_rows($old_times)) {
            $old_times = db_fetch_object($old_times);
            $old_times->eventrepeat_old_times = TRUE;
            _eventrepeat_update_nodes($old_times, NULL);
          }

Note the "$_POST['op'] == t('Submit')" check. This would seem to suggest that if you had a situation where you are loading a node and have also just somehow clicked a submit button, nodes will get updated. I tried some of the event view modules that have a submit button, but I was still unable to get this to happen.

hunmonk might have a better idea about this, considering it is from his original code. It might be a red herring, but it was a place I noticed updates were being called in a place where one would not expect. If the three of you have something else that might be relevant here, give a shout.

Additionally, can you let me know what timezones you guys are running your sites in?

Mountain timezone (gmt -7).

I have copied the data to my development environment I'll see if can spot anything. Also the production environment we use is hsphere based.

I concur there is nothing obvious that is triggering this. I've tried updating events, creating new one and nothing seems to cause a problem. I'm checked the cron job and it is doing nothing - exec time 0 secs. It certainly seems to be a set of 'events' that is causing this problem. The only thing that I can think of with regards our site that makes our events different from the basic event is that we attach images and locations to events. Rainy Day do you do anything like this??

What module are you using to attach images? Image attach?

Yes that is the module we are using for uploading images

I'm getting the same problem. It's not just for events in third month. All repeat events I create seem to be duplicated twice or three times for the same day. My repeat events are for second friday of every month and last friday of every month. I haven't tried the latest version of Event Repeat though.

Sean,

I found a variation on this within the 'eventproject' module that we've spoken about. I may have found two, see the support request I just filed.

It only happened when crawlers and users were viewing any month after the month in which the event had been created through the calendar of the event module. The hook within event that forces a render before the month display is put up was the culprit - at least it appeared to be. Even though I'd fixed it up I still have the problem, just on a much much smaller scale and I believe from a different root cause.

Because I was not using source control at the time that I fixed this on my fork in August, I don't have the exact delta (shame on me). The principle repair was in fixing an offset handling edge condition. I'll see if I can find the line or two I changed this evening if I have time. As I remember it, the error happened in the eventrepeat_render_nodes() call when calculating what to render. At some stage the last_rendered value was not having the appropriate GMT offset applied, which created a window for any GMT-x based event to get rendered twice. I'm sorry I don't have more information. Frankly I thought that I'd introduced it when overhauling eventrepeat to get rid of node creation and replace it with 'node projections' (small table entries for repeat dates rather than full on nodes) or I would have reported it to you along with the other problems I uncovered. I had seen this duplicating behavior in eventrepeat, but never identified it.

Hopefully this is the same root problem. I'll see if I can get more specific tonight. Without a change history I may not be able to give much more.

Here we go.

Everywhere else in the rendering function treats repeat_last_rendered as a date/time that needs to have the day offset applied except the line in this stanza:

         //save the new node
          node_save($repeat_data);

          //insert the newly created node into the repeat detail table
          db_query("INSERT INTO {event_repeat_nodes} (rid, nid) VALUES (%d, %d)",
          $repeatpattern['rid'], $repeat_data->nid);

          //update repeat last rendered for later saving to the repeat pattern
          $repeatpattern['repeat_last_rendered'] = $date_to_render->date_stamp;

I believe that last line should be

          //update repeat last rendered for later saving to the repeat pattern
          $repeatpattern['repeat_last_rendered'] = $date_to_render->date_stamp+$day_offset;

to keep the treatment of the value consistent. Without adding back in the day offset a teeny window opens up where events start to get created through the event calendar views.

At least that's how I remember it. Testing is obviously necessary as my work is on a fork. And, as noted in the issue I filed today, I'm still getting duplicated events - just not nearly as frequently. Without this one line change event duplication was out of control (in my forked version).

Thanks Scott, I'll try and test this tomorrow.

I am having trouble too, and in one case would up with 4000 extra versions of the same event!!

It seems to occur when someone uses the event repeat form in the wrong way, for example, saying it should be every monday but setting the end date to a Tuesday. Anyway, I am really looking forward to the new release.

In the meantime, if anyone needs to delete a whole lot of events, I don't recommend php admin, because if you erase the nodes from the table, it won't erase them from the events, node_revisions and any other related tables. I used this code to ensure the node was deleted properly and it worked well for me. It still only deleted about 120 at a time before timing out and it also depends on no other nodes having the same title as the node you are deleting.

I just refreshed the page every minute of so and was able to get rid of all by events. I added the print line so I could keep tabs of what I was erasing.

$sql = "SELECT * FROM node WHERE title = 'event title'";
$result = db_query($sql);
while ($x= db_fetch_object($result)) {
print "$x->nid $x->title".date('m/d/y',$x->changed)." $y
";
node_delete($x->nid);
}

I believe that Rainy Day committed this on CVS, which means it exists in both versions. I'm trying to run through some of the code that scott pointed to as a possible culprit and hope to have an answer in the next week. You'll probably want to wait, but it's up to you.

I think I am finally on to another way that repeating events get duplicated. I've opened a new issue for it and placed the details on http://drupal.org/node/93256.

This is a small patch based on Scott's comment #15 above. It adds $day_offset to the $repeatpattern['repeat_last_rendered'], which seems consistent with the other references to that element. If those people who are having issues could apply the patch and see how it goes, that would be very helpful. Scott's comments suggest that this might not totally solve the issue, but it should cut down on the number of times the duplications are generated.

Sorry it's late. Here is the patch that goes along with the post above.

You may also want to look at this issue: http://drupal.org/node/93256. It's a patch that might help in testing and trying to catch this generation of nodes from another source than the one above. Thanks Scott for your work on this.

You are welcome. I hope the mass-testing helps verify that this is indeed the problem. So far my logs continue to show that this is the root cause of the duplicate repeat events. Is it the last cause of duplicated repeat events? I sure hope so. I'm out of ideas.

Yowza.
I just had to clear up 57,000 bogus events today.
We released the site to the client all nice last week, and they managed to add a few events nicely, but obviously something went wrong with two of them (one weekly, one monthly) and all hell broke loose.
My quick solution was
UPDATE node SET status=0 WHERE type='event';
to clean up the site, then re-publish the real, individual events that we needed this month.

However, I'm hoping that someone can figure this out soon. Until then I'm disabling the module and telling them to maintain it by hand.
I remember looking at the code long time ago, but couldn't get too deep into the logic.
Good luck, guys!

That patch will greatly reduce the regularity of the duplicated repeats. Before I made that change to my site I was having duplicated repeats created every day or so. After the change duplicated repeats happened for another reason (http://drupal.org/node/93256) that took me a few months to identify. I'm glad this first run patch is working for you. Keep an eye out for this other version of the problem.

BTW the patch that Sean submitted to http://drupal.org/node/93256 does not reflect the logic in the code I gave him (more is in a comment on that thread), so wait for an updated patch before applying the other one.

I took a shot at updating that other patch as well. If someone can confirm that it works, we can move towards getting those and and pushing towards an official 4.7.

Hey Rainy Day,

The current HEAD version does not contain either this fix or the other one.

I was a bit confused by your comment:

The offset patch has stopped the duplicate events from being generated, but you say it is still generating an extra event or two every day. Are these the events at the end of the rendering period that are getting properly created by cron or are these druplicate events?

Thanks in advance.

Hey Rainy Day,

What is your "Render support period" setting defined as? The default is 2000 days (about 5 years) As I understand it, eventrepeat was written so that when you view dates in the future, the module checks to see if it needs to render additional events. So as long as you are within the render support period, new nodes get created when view a period of the calendar outside of the initial render period, as long as they have not already been rendered. If you are outside the render period, you get a "you are outside the repeat render period" message.

Could it be that the crawler is somehow hitting those dates in the future and generating the events? If so then, is this actually working as intended? If it is working as intended, is that OK and it was just unexpected or will this cause problems?

RTBC unless there are any problems based on the last two comments above.

Rainy Day - FYI the nodes you deleted are likely to not come back when 2008 rolls around. Eventrepeat keeps track of the furthest out date it generated and only creates new repeat nodes beyond that date and up to the "render period" of 2000 days [default]. Because it already creates these nodes in the future and moved forward in time it does not know that you deleted them.

I guess if you keep getting duplicated repeat events then they will come back. Heh.

If you knew that and already addressed it, just ignore my FYI. If you were not aware of it, reopen this issue in 2008 and ask for help in fixing the handful of your longer running repeat events that just won't show up on your calendar rather than creating a new issue. We'll be able to pick up right here where we left off. ;)

Scott

Committed to HEAD.

(See attached image) Is this related to the issues posted here or do I need to use views to produce this list without the repeats. I checked the eventrepeat.module file and it does have this patch in it (head version).

t4him, It looks like those events are not on the same day, which was the problem being reported in this issue. Please confirm whether those events are supposed to be mapped to those days. At first glance, it would seem that your block is correctly reporting the repeating sequence. Please correct me if I'm missing something.

If you are responding to the repeating event showing up multiple times in the upcoming event block, that is a known limitation with how event repeat currently builds out the repeat sequence. Let me know.

Sean, That is correct. I simply activated the 'canned' 'recent event' block, installed eventrepeat, created the [R]ecent event, and . . . 'the photo shows it'.

Maybe the second part of my question . . . Is there a way to 'suppress' this with 'views'? Anyway, I will continue to work with it AND monitor this post. Thanks for the quick response as well.

Cheers,

t4him

On supressing the event instances so that only the 'next' instance of any given repeat pattern is in the upcoming events block....

Views did not support that in July when I explored it with merlinofchaos, the author of the views module. The challenge is the group by on the repeat ID that is needed, which views did not support well. Even if it did, the query to pull back the 'next' instance of a repeat pattern AND regular event entries which do not repeat is too complex - as far as I know - for views to handle out of the box. My hand rolled solution used a UNION, which is not something that I believe is in line with Drupal's database abstraction layer guidelines and thus is not a solution that can be comitted.

This would not complicated to do if eventrepeat stored a single node for the full repeat sequence and kept just the upcoming dates in an ancilary table, which is a one of several design that Sean is contemplating in a significantly redesigned eventrepeat module.

Moving this back to fixed. If you want to create another issue concerning the block, feel free to do so.