This issue report may have two purposes. It could help site builders like me who are using Views-6.x-3.x-dev and unable to get view attachments for Year, Week and Day working. It may also indicate to the module maintainers that Calendar still has a bug in the way options like calendar_type are defined and ultimately exported via views.

Site Builders
So I followed the workflow I have successfully used in the past to create a new calendar view on a fresh install. I enabled the default calendar view and cloned it. However, when I went to the calendar page the links to the other calendar displays were missing. I retraced my steps and discovered that the calendar period (under Calendar Settings) was defaulting to Month for each of the view attachments. This is apparently because the cloning operation which I gather is an export/import operation was not exporting the calendar period (calendar_type in the code) because it wasn't defined properly. To resolve the issue I had to edit each calendar period and select the value appropriate for the attachment. [Moreover, I also had to do this for the Month view even though it looked on the face of it that its option was set correctly. But that was just the default value rendered in the view form - the option was evidently not actually stored properly in the database and so the link to the Month view wasn't output to the calendar page. So, I had to update the Month display attachment for completeness.]

Module Maintainers
It looks like the cause of this issue was raised previously #966394: Dayly view is empty, but was bounced to the Views issue queue #979474: Clone view: Custom module settings are not cloned? and that's as far as it got. I looked through the commits to see if it has been resolved and couldn't see tags for calendar-6.x.2.4 or calendar-6.x.-2.x-dev indicating that it had. I tried to understand Earl's point about options_definition but the code in calendar_plugin_display_attachment.inc looked like it was following Views API correctly. Hopefully, someone who understands what's going on can take a look at this as I suspect it is causing grief to others besides me. My apologies if this is a non-issue or has been addressed in elsewhere in the queue.

Comments

Status:Active» Fixed

I made some changes in both Calendar and Date and I think cloning/exporting is now working correctly.

Status:Fixed» Needs work

Unfortunately, despite the hard work you put into these changes, cloning is still not working correctly.

I built a brand new platform/site environment with the following modules:

Drupal 6.20
Views 3.x-dev
Date 2.x-dev
Calendar 2.x-dev

The calendar period for each Day, Week, Month and Year view is still defaulting to Month after cloning the calendar view that comes with Calendar.

I am having the same or a similar issue. If I compare the default view and a cloned or exported/imported view, the Calendar style settings are not the same for Year, Day, and Week. I cannot recreate the settings since they are custom.

I am running the current dev of Date, Calendar, and Views as of 11/4/11.

Confirmed. If I import a calendar from code or use it in a Feature, and I'm using Views 3, I have to override the calendar and add back in the Date argument. This is what seems to be missing.

The error message I see when editing a newly-imported calendar is:

The Date argument in this view must be set up to provide a default value set to the current date. Edit the argument, find 'Action to take if argument is not present.', choose 'Provide default argument', then select 'Current date'.

The "Current Date" radio button, which was checked before export, is unchecked on import. This also means I can't keep a calendar in code.

Version:6.x-2.4» 6.x-2.x-dev
Category:support» bug
Status:Needs work» Needs review
StatusFileSize
new972 bytes

The problem is calendar_plugin_display_attachment class option_definition trying to figure out a default when the data is not yet there.

Status:Needs review» Reviewed & tested by the community

The patch fixed it for me! Thanks!

#5 works for me too.

Me too. Could this get committed?

This issue just bit me again. Please commit this.