When I clone the default view created by the Calendar module, the custom Calendar settings are not cloned. This leads to some problems, as described on this issue: http://drupal.org/node/966394

I don't know if that's actually the expected behaviour, a problem on views or a missing hook on the Calendar module.

Can somebody spot some light on this issue? Thank you.

Comments

Letharion’s picture

Letharion commented
Assigned: Unassigned » Letharion
Status: Active » Postponed (maintainer needs more info)

I can't reproduce this. What I did was changed the published filter to "published or admin", cloned the view, and checked that the setting was still there.
I probably don't understand what you mean by "custom Calendar settings".

jorge.suarez’s picture

jorge.suarez commented
Status: Postponed (maintainer needs more info) » Active

By "custom calendar settings" I mean custom module-related settings. Maybe that's not the better name to call that options.

Just enable the view, then edit the display "Day View". There will be an options block named Calendar settings with one setting: "Calendar period: Day". That's the kind of settings that won't be cloned. Just clone the view as-is, and take a look at the cloned view.

Thank you for taking a look at this.

Letharion’s picture

Letharion commented
Assigned: Letharion » merlinofchaos

Confirmed.

@merlinofchaos
Quote by KarenS from the issue linked to in the OP:
"I noticed that too -- the export does not include custom settings added by other modules like Date. It is either a views bug or there is some views hook that I don't know about. Can you post a report on the Views issue queue please?"

karens’s picture

karens commented
Assigned: merlinofchaos » Unassigned

Just tracking this issue, it's actually the export that is missing data, the clone process then uses the export to create the clone. Not sure yet why my custom settings don't get exported.

merlinofchaos’s picture

merlinofchaos commented

In Views 3, for settings to be properly saved and/or exported they must exist in the option_definition() for the plugin.

In Views 2, some settings could be saved or exported witout being in the option_definition, but in 3.x I tried to clean up the unwanted trash that gets into the arrays. That means you have to be very explicit about what isn't trash.

merlinofchaos’s picture

merlinofchaos commented

Yes, I just checked current calendar.module code. It's using ::options() rather than option_definition(). I'm somewhat surprised; the ::options() method was deprecated before Views 2.0 was officially released, I didn't realized that use of this method was so widespread in contrib. :/

merlinofchaos’s picture

merlinofchaos commented
Status: Active » Closed (won't fix)

That means this isn't a Views issue at all.