Environment:
Date 7.x-2.0-rc1
Drupal core 7.10
Views 7.x-3.0
Chaos tool suite (ctools) 7.x-1.0-rc1

I use Multi-day style (in the Month Options) as "Display multi-day item as a single column" in order to avoid
Nodes without an end time are assigned the "multi-day" CSS class in the calendar month view

Now I get a series of notices and warnings every time I choose "Day" at the Month View:

Notice: Undefined index: groupby_times in template_preprocess_calendar_day() (Zeile 267 von /home/www/vtad7/sites/all/modules/calendar/theme/theme.inc).
Notice: Undefined variable: divisor in template_preprocess_calendar_day() (Zeile 280 von /home/www/vtad7/sites/all/modules/calendar/theme/theme.inc).
Warning: Division by zero in template_preprocess_calendar_day() (Zeile 280 von /home/www/vtad7/sites/all/modules/calendar/theme/theme.inc).
Notice: Undefined variable: divisor in template_preprocess_calendar_day() (Zeile 281 von /home/www/vtad7/sites/all/modules/calendar/theme/theme.inc).
Warning: Division by zero in template_preprocess_calendar_day() (Zeile 281 von /home/www/vtad7/sites/all/modules/calendar/theme/theme.inc).

The error Series occur only one, paging thru the Days doesn't generate more errors.
Also the Day View starts a the beginning of the Month instead of the actual date (see www.vtad.de at the calendar)

The Day entries are displayed Correctly

Seems to be related to the issue http://drupal.org/node/1248002#comment-5418860 where this errors occur for the week view.

Is there an easy way to suppress the DAY Link?

Files: 

Comments

I don't know if is caused by a Views Grouping error but http://drupal.org/node/1235994#comment-5393400
looks similar (there is also a patch)

I am getting a similar error backtrace, but on the Week view with 7.x-3.x-dev. The error mentioned in #1 can apparently be worked around by disabling the core RDF module. However, I tried that and it doesn't fix the Week view error.

Error happens also with Views 7.x-3.1

Status:Active» Fixed

Date 7.x-2.0-rc2 seems to fix this bug.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Version:7.x-3.0-alpha2» 7.x-3.x-dev
Status:Closed (fixed)» Active

Installing an old version (7.x-2.0-rc2) does not fix the issue for the current release. So I'm re-opening the ticket. I'm having the issue with the latest dev version (7.x-3.x-dev).

Notice: Undefined index: groupby_times in template_preprocess_calendar_day() (line 273 of /home/test/domains/www.test.org/sites/all/modules/contrib/calendar/theme/theme.inc).

Status:Active» Postponed (maintainer needs more info)

Not enough information to reproduce. Plus I can't tell if you are using the latest version of Date and whether you are trying to display a view created in Calendar 7.2 (which will not work) instead of re-creating the view in 7.3.

Status:Postponed (maintainer needs more info)» Fixed

Finally was able to replicate this and find a fix.

http://drupalcode.org/project/calendar.git/commit/4389f3d

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Priority:Normal» Major
Status:Closed (fixed)» Needs work

Bug still exists in latest dev and 7.x-3.4. Commit http://drupalcode.org/project/calendar.git/commit/4389f3d not applied. Please check.

It appears this commit reverted the changes made in #8:
http://drupalcode.org/project/calendar.git/commit/9f4ee153a96eeaf149a285...

I am still experiencing this issue with Calendar 7.x-3.4 and Date 7.x-2.5. Is there any fix or patch available? Thanks.

Look at commit from #10.

Worked fine, thanks.

StatusFileSize
new1.28 KB

Since the commit mentioned in #11 is true I have created a patch and test it from KarenS #8 post.

Status:Needs work» Needs review

Status:Needs review» Active

The current code ($view->style_options['groupby_times']) is the proper functionality. The $view->date_info->style_groupby_times is used to calculate all of the offsets (every half-hour, hour, or custom). Even though this satisfies the conditional in the patch, it breaks the ability to have events span from their start time to their end time.

That being said, I've been struggling with the Calendar today. I had a Calendar exported as a feature that was missing a $handler->display->display_options['style_options']['groupby_times'] declaration for the week and day views, which caused me to get the same notice. I'd recommend either manually recreating your view in the current version or trying to export the view, make sure groupby_times exists for your view page in the day and week pages (which, at my quick test, doesn't seem to be in the exported code), and then reimporting.

I'm marking this active, as I don't think there is an issue with the current version and the patch will not fix it. There may be broken functionality from an upgrade standpoint, as well as the View export functionality, but I'm not sure about this. A braver person can mark it otherwise.

#10 patch works. Can this be committed to the next release. Thanks.

Status:Active» Reviewed & tested by the community

Can also confirm that the patch in #15 is working.

Status:Reviewed & tested by the community» Needs work

As stated by jbylsma in #17.

Even though this satisfies the conditional in the patch, it breaks the ability to have events span from their start time to their end time.

So I'm moving this issue back to needs work.

I was able to fix this with jbylsma's advice in #17. When group by time is set to hour, it doesn't export. I changed this setting to 'half-hour', exported the view, and there it was. I was then able to manually copy this into the view being exported into my feature and change its value to 'hour'.

@vinmassaro can you submit a patch back with your fix please?

I didn't fix this in the module code, just in my feature. I added the following inside each display in the exported view in my feature:

$handler->display->display_options['style_options']['groupby_times'] = 'hour';

Same issue with OpenOutreach profile rc9.

I'm having this issue as well.

Notice: Undefined index: groupby_times in template_preprocess_calendar_day() (line 269 of D:\htdocs\d7sb\sites\all\modules\contrib\calendar\theme\theme.inc).
Notice: Undefined index: groupby_times in template_preprocess_calendar_day() (line 273 of D:\htdocs\d7sb\sites\all\modules\contrib\calendar\theme\theme.inc).

This error is showing up on my day view. I'm not actually sure what changed to cause this error but I suspect it was when I updated my date field to allow repeating dates. The error shows up when I view a day with a date that doesn't repeat though... I must not have something set properly in my day view.

Calendar 7.x-3.4
Date 7.x-2.6

Any advice on settings I should check? This looks really bad for my end users...

I believe I've found a way to reproduce this. So yesterday after I posted comment #25 above I decided to try playing with my calendar day view settings. Before I continue it is worth mentioning that I'm using Features for my project: Features 7.x-1.0. I capture all of my event calendar views in a feature called Events and when I make changes to any of these views push the updates out to my live sites using this feature.

Now, having said that, yesterday I went into the calendar day view to have a look around. Under the FORMAT section the first line reads Format: Calendar | Settings (I clicked on this Settings link) I had no idea what was causing the problem because as far as I could tell everything looked great. My settings were as follows:

Calendar Type - Day
Time Grouping - Hour
Overlapping time style - Display overlapping items, with scrolling
Field grouping - n/a
Fields to hide in Multi-day rows - none selected
(I only have two fields, title and field_date)

Playing around I decided to hide field_date under the multi-day rows section. When I saved my view I noticed the errors went away. I was thrilled so I repacked my feature and pushed it out to production thinking that would fix the bug. Unfortunately it didn't. I was baffled once again. Doing a side by side comparison between my dev copy where my features are created and my live site the two views looked identical. All of my view settings were coming across fine. The field_date field I'd just hidden in my feature update was indeed hidden on the live server but the error persisted.

Going back to the dev server I unchecked the field_date under multi-day rows to display it again and the error was still gone. It was beginning to look like it wasn't the change in the field that actually made a difference but simply SAVING the settings in this section of the view definition. One one of my live sites I decided to do a test. I went to the exact same section of the view definition (FORMAT: Calendar | Settings) - I changed the time grouping to half-hour and then back to hour and reapplied the changes. I then saved the view again. The error went away.

In essence it doesn't look like Features is properly capturing these settings. When I look at the definition for the view in my feature code I do not see ANY information regarding the time grouping. Here is the first part of my view definition from my feature code including the style_options values:

/* Display: Event Calendar Day Pane */
  $handler = $view->new_display('panel_pane', 'Event Calendar Day Pane', 'panel_pane_5');
  $handler->display->display_options['defaults']['title'] = FALSE;
  $handler->display->display_options['title'] = 'Events Calendar (Day View)';
  $handler->display->display_options['display_description'] = 'Provides day view for events.';
  $handler->display->display_options['defaults']['hide_admin_links'] = FALSE;
  $handler->display->display_options['defaults']['style_plugin'] = FALSE;
  $handler->display->display_options['style_plugin'] = 'calendar_style';
  $handler->display->display_options['style_options']['calendar_type'] = 'day';
  $handler->display->display_options['style_options']['name_size'] = '3';
  $handler->display->display_options['style_options']['mini'] = '0';
  $handler->display->display_options['style_options']['with_weekno'] = '0';
  $handler->display->display_options['style_options']['multiday_theme'] = '1';
  $handler->display->display_options['style_options']['theme_style'] = '1';
  $handler->display->display_options['style_options']['max_items'] = '0';
  $handler->display->display_options['style_options']['multiday_hidden'] = array(
    'field_date' => 'field_date',
  );

As you can see the necessary line to define the time grouping does not exist:
$handler->display->display_options['style_options']['groupby_times'] = 'hour';
(as mentioned in comment #23 above)

I'll do as suggested and manually add this to my feature definition. I'm concerned however that the next time I recreate this feature my manual change will be lost. We definitely need to be sure this value is being captured by features.

Just did another test where I made a change (unrelated) to this view and recaptured it with features. The setting - $handler->display->display_options['style_options']['groupby_times'] = 'hour'; - is not being captured by features. I did however manually add this line to my feature code before deploying it to my live site and the error did not reappear.

CopperBot, if you ignore Features and instead use the defaul export capability of Views do you have the - $handler->display->display_options['style_options']['groupby_times'] = 'hour'; or is it still missing?

If it's still missing then it would be Views and not Features. Just double checking :)

FatGuyLaughing - Would you believe I've never really looked at the default export capability of views before? Hah! You learn something new about Drupal every day! I did a quick check and using the default export capabilities of views the style_options groupby_times value is still missing.

If it's still missing in the default Views export capability, then there is probably a chance that the code for the date module is doing something wrong. There is still a chance that Views export is missing something, but less likely.

So it sounds like we need to further investigate how a view gets exported and when defining fields to be used in Views is there some special way we need to set it up so that Views knows "Oh hey I'll export that for you".

Confirming the problem here. A feature of an events calendar.

Thanks #26! worked for me! I've just changed settings saved and turn them back! now everything looks fine.

Status:Needs work» Needs review
Issue tags:+calendar

Note: This applies to module versions 7.x-3.4 and 7.x-3.x-dev.

Found a similar error message when selecting the Week View and as per this report, the Day View. Some Google-Fu'ing on the Week View error messages, came across this bug report fix and patch (I just did the "fix" portion initially for resolution).

Performing the fix on both the Week and Day Views (adjust accordingly of course between the different Views) resolved this for me. Would like further review and input since I am just a site builder, not a coder regarding the patch. ;-)

TIA.

It looks like the patch referred to in comment 33 is for an old version of the calendar module -- there is no longer a includes/calendar.views_default.inc.

Status:Needs review» Active

Setting to active since there doesn't seem to be a patch for the current code.

@xenophyle

Is there a way to replicate this "bug report fix" I mentioned then via a patch? If I am understanding the method behind the "bug report fix" process, it is just initializing some variables.

Disclaimer: I am just a site builder, not a software developer/engineer type. ;-)

Priority:Major» Normal

Hi LinuxETC,

My understanding is that this problem comes up when the calendar view has been exported and imported. (Looking at the code, it looks like any missing variable initializations were added in a while ago.) For me the error did go away when I followed the steps you linked to, and there was also a patch that showed how to edit the export code as an alternative. I am looking for a patch that will cause the export code to have the missing line included when it is generated in the first place, so I don't have to follow these steps every time I import/export this view, which happens frequently since I use Features to synch my site.

Unfortunately I have not been able to figure out how to do this or where the code is that generates the export.

(Setting the issue priority to normal.)

Thanks LinuxETC — the UI fix you recommmend is a good one (I didn't apply the patch because it was for the Week view and my problem was with the Day view). That solved my problem.

I have posted a summary of this problem that has been noted several times in the issue queue. I have also posted new patch. See #2160183: Undefined index: groupby_times - FIX

#26 also worked for me while using:

  • Drupal 7.26
  • Date 7.x-2.7
  • Calendar 7.x-3.4
  • Views 7.x-3.7
  • and a cloned calendar view made with the wizard

Thanks.

Hello

I don't have a patch that fixes the issue, but I do have a workaround solution for all the fellow features users.
I maintain a distribution and manually fixing things by saving a view is not a option for me.

I thought I'd share this so that it may save some time and trouble when manually editing exported views (don't do that):

<?php
/**
* Implements hook_views_default_views_alter().
*/
function myfeature_views_default_views_alter(&$views) {
  if (isset(
$views['events_calendar'])) {
   
// fix issue https://drupal.org/node/1397986 by setting the missing option
   
$handler_day =& $views['events_calendar']->display['day']->handler;
   
$handler_day->display->display_options['style_options']['groupby_times'] = 'hour';
   
$handler_week =& $views['events_calendar']->display['week']->handler;
   
$handler_week->display->display_options['style_options']['groupby_times'] = 'hour';
  }
}
?>

Of course you have to adapt it to your view by changing the name and also the display id.
I know this is not magic, but a lot of people posted that manually saving the view again solves the problem. So I thought I chip in the code version of manually saving the view.
(Don't forget to clear the caches)