Posted by jredding on April 11, 2007 at 4:41pm
Since the Date+Calendar session at OS-CMS there has been a lot of speculation about the future of the event module. I'm fairly vested in the Event module and have plans to become even more invested in it. I like to discuss the evolution of "Date+Calendar" CCK type vs. the use of the Event module. Personally I love the event module and would love to see it progress.
So my questions are:
Where is the Event module going and where would people like to see it go?
Date+Calendar (CCK) is this an eventual replacement for the event module?
In talking with other people this seems to be a pretty hot topic right now (well lukewarm at least).
Comments
Date + Calendar can replace event today
AFAIK, Date + Calendar can be configured as a full replacement for event module today, plus actually has more features (e.g. iCal import).
In fact, I'm not clear on what, if any, future there IS for Event.
what about...
What about
Event repeat and RSVP? these two items can't be duplicated with Date+Calendar.
Not to mention events are handled slightly different than nodes keeping a cleaner backend for those sites with 10s of thousand of events (we generate about 80-100k year for a single site)
-Jacob Redding
-Jacob Redding
Older code
Um....all events ARE nodes. I'm scratching my head on this one and looking at the history of event, and can't find any example of where the event module didn't use nodes....
Event repeat is something that could be adapted for Dates + Calendar, as could RSVP (which shares some stuff with Signup, which is more generic). AFAIK, both of those modules haven't even been update for Drupal 5, so perhaps a good time to "port" them to Date + Calendar.
Event was built and maintained many versions ago. In many ways, Date + Calendar are re-implementations with the clean APIs of CCK + Views, with the flexibility and data manipulation that those sets of APIs bring.
You're right
all events are nodes. I need to stop typing so fast and read what I write before I hit "submit" ;)
my comment was more on the handling of start/end date/times. That information is not stored on the node and is handled differently than the CCK version. It seems a bit cleaner at first glance but then again the CCK version is still in flux and could be cleaned up.
I've been talking with a few people about events and it seems to be a holy war ;)
Maybe our application is a bit specific since we are scheduling a television station with it and the start/end times are exactly what we need and the Event module has everything we need out of the box. the CCK version is a bit more clunky to use for our specific application. (Events every half to full hour on a 24 hour day).
Its worth mentioning though the Event Repeat has been revved to 5 and is being considered to be modded to accomodate both the event module and the CCK version. This leads me to believe that Event module isn't going anywhere and will run parallel to the CCK version.
http://drupal.org/node/87600
I guess I'm just trying to figure out which is the safer bet. Reworking our code to work with the CCK version now or sticking with the Event module. Especially since we're considering moving 10s of thousands...
The event module has been handling this high workload (tested it with about 30k) with ease, I'm sure the CCK version will too I'm just looking for opinions for others.
(attempts to dodge holy war battle... but has thus far been unsuccessful)
-Jacob Redding
-Jacob Redding
Not trying to get holy
...but been burned by event in the past.
CCK + Views etc. seem a cleaner model. Configuring start / end is not hard -- it's just that it does need to be configured vs. out of the box with Event. If you're going the customization route, Date/Time may be easier for you.
Long story short...you need to do your own due diligence, but I think you'll see that continued work on Event is from people with legacy investment (4.7 and earlier) in Event content, and that forward momentum is clearly with Date/Calendar. YMMV.
Note: the CCK model doesn't "store" the Date/time info (or anything else) "on" the node either....same as event.
Not a holy war
I hope it's not really a holy war, because that was never my intention in creating these modules :-)
If you're using CCK and Views extensively already, the Date + Calendar combo seems to me to make the most sense. If you've got a lot of legacy investment and the event module does everything you want it to do, you may want to stick with Event. Event is also good if you want a simple turn-key solution, because Date + Calendar involves more modules and more configuration, although I think they also provide more customization possiblities.
Event Repeat will be updated to work with both Event and Date + Calendar, discussion at http://drupal.org/node/87600. The Signup module will probably also be updated to work with both Event and Date + Calendar, discussion at http://groups.drupal.org/node/3430. Others may follow.
I have just added a Date Copy module to the 5.x version of Date that will import events into CCK Date nodes, so there is an upgrade path. Hopefully that will preserve your ability to postpone a decision until later if you're not sure.
My understanding is that Killes intends to keep working on the event module. He's in the process now of changing it to use a datetime field instead of a unix timestamp. Anyway, I would say that for now, at least, there are two approaches available so pick your poison!
Excellent topic and feedback!!!
Thanks to jredding for bringing up this issue because I, too, was wondering which path I should take with regard to Event or Date+Calendar.
And an equal big thanks to Boris and Karen for their excellent feedback I'm reading here and for the links that Karen provided. As Boris mentioned, one must conduct due diligence in determining what path to take, but the community certainly benefits when folks like Boris and Karen provide their candid observations as to what works with what, what's being worked on for future releases, which modules are needed to run with certain modules, which modules are "turn-key" and which modules require a bit of configuring. At first, being a non-developer, I considered going the Event "turn-key" route, but I'm going to bite the bullet and experiment with Date+Cal to see if I'm capable of configuring it because it seems to me that it's the path I should take.
The comments are all very helpful. If other folks want to add their observations and suggestions, thanks in advance!
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
Walt Esquivel, MBA; MA; President, Wellness Corps; Captain, USMC (Veteran)
$50 Hosting Discount Helps Projects Needing Financing
news from signup.module
so, in summary, signup's full functionality currently only works with event.module, but most of the functionality works fine without event at all. this will all change in the near future (probably on the order of days or weeks, not months) and signup will be equally happy with event or date.module. in the medium or long term, signup might require views and/or CCK, and quite possibly date_api (though it'd probably still work with event.module for a long time -- since there's not much event-specific code, it's not that much of a burden to keep it in the module).
I don't think CCK should or
I don't think CCK should or even could replace anything. In this case CCK + Date and Event module serve two different audiences. If you're not a developer then you'll lean on CCK + Date to get the job done, if you are a developer, then working directly with the Event API is much easier, cleaner and is the way to go.
We've found the creation of new modules to be very easy, and have recently removed CCK from our website entirely. We're developers, CCK isn't necessarily targeted at us.
So I guess I don't see CCK replacing Event module, this isn't a holy war, its just a matter of choosing the right tool for your team, expertise, and particular situation.
Utterly perplexed
Trying to figure out how to use Date and Calendar and CCK to make an "event" content type, and get anything remotely like what the Event module does...I've read all the readmes for the modules...but I can't figure it out. The content type just doesn't show up...and I can't see any way to configure the modules.
Can anybody point out what I might be missing? I'm definitely not a "programmer type," and this is for a new Drupal system, so by the conversation above, it sounds like Date/CCK is the way for me to go...if I could figure it out!!! -Pete
Pete Forsyth
Puddletown Tech
service for Macintosh, Windows, and Linux computers
Have you read the Calendar
Have you read the Calendar and Date handbook pages? I spent quite a bit of time trying to document how things work. You also should have at least a basic idea how to create a new content type and add a CCK field to it. If you haven't tried that before, I'd start with a simple CCK field to be sure you understand how CCK works, then try to get Date and Calendar working.
how about creating/offering default simple cck types?
This is a problem with the CCK / Views approach to things in general - the CCK/Views solutions are more powerful and adaptable but have a barrier that scares away newcomers to drupal, so they are left with the prebuilt modules that offer out-of-the-box solutions. Wouldn't it be easy to solve this problem???
Older modules were created that had a very specific purpose (Events, Real Estate Listing, Portfolio, Image, ...)
Now, with the advent of CCK and Views, all these custom types can be created, BUT the user has to configure them instead of them being ready to use out of the box.
One of the things that makes Views so easy to learn how to use is the fact that it comes with a bunch of Views templates (especially if you get the bonus pack) and you can then clone and modify these views to suit your needs. Beautiful and simple to learn!
It would be awesome if CCK would do something similar. In other words, couldn't some basic types be written into the modules or as an optional module extension? This way, when a user installed a certain cck field type and enabled the optional default simple type, then going to create content would already have the new content type ready to go. Below are some examples of what I mean:
Events - replace Event module with Calendar+Date (+CCK +Views)
Event-Basic
Event-Multiple Times - for events that have more than one date/time (ie. a television show might have multiple times when the show airs, but the show itself should be a single node with multiple times) I set up all my events to allow multiple times, but this is not always desireable.
Images - replace Image module with Image Field + ImageCache (+CCK +Views)
Image CCK type
Image Galleries CCK/Taxonomy style
The weakness of the CCK image approach is uploading/inserting images, but I think Asset Manager (may handle any type of asset - images, video, audio, pdfs, etc.) has a great approach to handling this. Check it out here: http://drupal.org/project/am
Is there a tutorial anywhere on how to write a module that creates a CCK type? Would the CCK export feature help in creating this kind of module? If I knew how, I'd be happy to create these modules and contribute them to the respective projects or create my own package.
Obviously modules like this could be created for all types of content. It seems that a lot of this work is being done in the creation of installation profiles, but that solution isn't as granular so if a user needs features from multiple profiles or just a subset of the features, they have no way of implementing them without manual configuration, which is unreasonable to expect from users who are new to drupal.
I think that these simple module additions would greatly increase the adoption of this new and improved way of doing thing in drupal and would vastly speed up the learning curve for how to use CCK types in general. It would be great for the community.
Update?
I'm fairly new to the discussion and just wanted to hear any updates on Event vs. Date/Calendar development.
So would most people suggest
So would most people suggest solely using a Date/Calendar model for creating events as opposed to using event module?
Both Are Relevant
IMHO, Event and Date+Calendar are BOTH relevant.
If you want a basic "plug and play" solution (as most users do), then Event is your answer. It ain't pretty, but it gets the job done simply and easily.
Date + Calendar is a very robust solution, but it comes with a steep learning curve to take advantage of the advanced functionality. As "MikeyLikesIt" said, it's not an out-of-the-box solution. Documentation is spotty at best and most users do NOT want to have to install 3 different modules, configure new content types and modify views JUST to get a basic event calendar working.
I want to express my appreciation to the developers and encourage them to continue work on BOTH of these valuable Drupal solutions.
repeating events with date+calendar: overriding instances?
What I'd like to do is create an event node, set repeating date logic, and be able to override individual instances; for example, where only on some dates a class time needs adjustment while the rest of the series stays same, or if i want to provide different class agendas for each class session.
the eventrepeat module does this well, by creating a separate node for each instance of a repeating event, and provides logic to modify only one instance, future instances, or all instances.
Is this achievable with date+calendar?
not yet
as far as i can tell, it's currently impossible to override an instance using date/calendar. the problem arises because each event, regardless of its repeating pattern, is represented by a single node. there would need to be a data structure to capture changes to specific instances, perhaps creating related nodes when changes are made to an instance. the event module deals with this use case by creating a separate node for each instance; that makes the data simpler, but it can make browsing content in the admin pages a little overwhelming. overriding an instance is a pretty important use case - imagine trying to use the signup module with date/calendar and finding you've signed up for every instance - but it doesn't seem simple to implement. (i'm curious what KarenS thinks...)
-- i'd like to add that it is possible to set an exception in the date repeat api, and then manually create another node for your "instance". it's just not very user-friendly.
You can override individual
You can override individual dates with an exception list, and an addition list is planned, so you should have good control over the dates in your repeat. The current code puts all the dates into a single node, so it won't work well for the purpose of linking agendas and other things to specific instances.
Sometimes having all the repeats in a single node is a benefit, especially if you're doing something like repeating a reminder every day for three years. You wouldn't want a separate node for each of those items :)
But sometimes you do want a separate node for each item. Adding another way of doing repeats that would create separate nodes is something I'd like to add in the future. The repeat logic is ready to go and will work fine, we just need a way to tie the separate nodes together somehow. Creating separate nodes for items that need to remain linked together is tricky, that creates all kinds of problems in the Event Repeat module, too.
thanks for the quick response
that's pretty much what i was thinking.
the event module asks after you click to save a node whether you want to apply changes to all instances, or just the current instance. that'd be a sensible ui for date/calendar as well, but currently the edit page (or signup page, or whichever page modifies an event) doesn't have any idea of which "instance" you might be trying to edit - the url only gets you as far as the node, which encompasses all "instances". it seems to me that identifying which instance the user wants to change, and making that instance identification available to dependent modules (signup being my perennial example), is the thorniest part of supporting instance divergence.
(perhaps signup is a bad example for date/calendar, however - in the case where events require signups, nodes would be created for every instance to store the signup relationship, which would turn the date/calendar edge case into the event standard case: every instance has its own node. it would probably make sense to use event, in that case [as you suggest!], but if you'd already implemented date/calendar and then needed to support signups as a later feature request, it would be nice to have a sensible way to support many independently modified instances without creating a panoply of nodes, as in your "every day for three years" example. there must be a better way!)
it could be that creating a dependent db record, rather than a node, for each modified instance would be cleaner, though i still don't know how to best identify event instances to for modification by other modules. the difficulty in generating an identifying url seems to me:
1. we'd need to know from context which instance is relevant (day on calendar, for example)
2. we'd need to know which date field is relevant
in the calendar, that seems easy enough, as the calendar view settings determine which field is relevant, and the calendar format gives enough context to know which instance is relevant. my concern is with other possible views: maybe "available classes" or "upcoming workshops", where the url generation would perhaps have a harder time introspecting the custom view.
The 3 modules it takes to
The 3 modules it takes to get Date + Calendar working are often modules that you'd install anyway -- CCK and Views at least are on almost every site I've seen -- so that is not really a problem. And you don't have to modify Views to get it working, you have to modify the Calendar View by identifying which date field you want to use, since you can use any date field in a calendar.
I agree that Event is a simpler, out of the box solution if you want a basic calendar of current events and it works the way you want it to.
If you want to have the ability to alter it in various ways, Date + Calendar is probably a better solution. Because it uses Views, you can filter your calendar by any combination of criteria you like, and you can do things like display the 'Day' view as a teaser list while using a traditional calendar view of the month. And you can leave time out of dates if you don't want it, and set it up so the input and display are in any format you like. But yes, definitely it takes more setup.
As to repeating events -- Date + Calendar currently creates repeating events as multiple values on a single node instead of creating multiple nodes. That is something that some people preferred. There's a feature request to add different nodes for each one but that's not implemented yet.
The Date API has a repeat API that the Event Repeat module may start using because it is a huge bear to maintain repeating date logic in two places, and if it does, repeating events will take multiple modules either way -- Event + Event Repeat + Date API or Date API + CCK.
The D6.2 version of Date + Calendar is broken right now -- it worked earlier but both CCK and Views have changed so it needs an update, but that's my project for this week, so I hope to have it working again soon.
Filtering issue with Repeating Date API field in custom node
I have created a custom "event" node that uses the Repeating Date API for creating a repeating event schedule (i.e. Every Thursday between 2 and 4pm, beginning Oct.21, 2008 to Oct.21, 2010).
What I seem to understand (my assumtpions):
1. That the repeating date api uses iCal-formatted formulas to calculate repeating dates;
2. The use of this formula results in only having one (1) node;
3. My "custom" event, which is using a repeating date api field, has an iCal repeating date associated to it - I named my custom field "field_event_date", which is in the custom content type "new_event";
4. When I retreive the "field_event_date" field inside a custom view, it simply prints out the iCal formula in it's entirety (see attachment).
5. There must be a way to separate out the "next event" date and not show event dates that have already passed and dates beyond the next event?
6. That everything I've said here makes sense.
Thanks,
Mark
And I know everyone would
And I know everyone would like more documentation of Date + Calendar. If I ever had the time, I'd like to do some screencasts showing what it looks like and how to set it up. I just never have the time.
And the D6 version of CCK has an API so it should be possible to create an additional module that could be packaged with the others that would set up all the things you need to have a working Date + Calendar event system without setting everything up manually. That would be a nice thing to add to the feature request list.
For the 'locked' issue, CCK
For the 'locked' issue, CCK could choose to honor the locked flag for a content type. See http://api.drupal.org/api/function/hook_node_info/6
I'll be happy to help with screencasting
Drop me a line when the module's ready to be used in 6.3 (or put a note here signalling where I should be looking. I've currently got a "fatal error" so I know I can't start screencasting today :)
how about
Calendar + Date being in Acquia's supported module list, carry any weight?
However, no solution YET for EventRepeat & Signup ...
-najibx -
<a href="http://www.successideaweb.com>Drupal web developer | designer in Malaysia
Signup now supports CCK date fields and D6
See http://groups.drupal.org/node/16747 for more...
Demo of Calendar + Date in action?
Hi
I'm new here. I run a site that uses Event as one of its central planks. I am very concerned that it has not been upgraded to D6. It is just this one module that is keeping me stuck on D5.
I don't have a problem with configuring stuff but I would like to see Calendar + Date in action before going to too much trouble so that I can decide if it would do my job. Can anyone point me to a live site on which I could see what it looks like?
This is just what I love
This is just what I love about Drupal. In my lonely thoughts about technical choices for the sites I'm building, I often ask myself questions like should I use Event or Date/Calendar. Then I google it and find a whole thread with history like this one. All the thinking is almost already done :)
great discussion.
this is the kind of discussion I needed to move into Calendar+Date module, thanks KarenS and others for your positive feedback and suggestions, subscribing...
bending technology to fit businesses.
Event vs Date+Calendar
I know this is an old discussion but ive found myself @ a sort of crossroads with this. In my current project I created a CCK Date calendar setup which works great. Now I am onto og and specifically the og_calendar module. It requires event module. Is it ok or even smart to also install the event module and keep my CCK date calendar which is a sitewide events calendar? Or should I scrap the cck date calender all together and go with event only?
Cheers!
Ok I found this... Looks
Ok I found this...
Looks like I can leave out og_calendar and Event and stick with my cck date build
I am going to try this with panels3... wish me luck!
http://agaricdesign.com/note/drupal-calendar-implemenation-organic-group...
I have cloned og_calendar
I have cloned og_calendar with date+calendar if you need to know how that was done let me know and I will give you a views export.
bending technology to fit businesses.
Yeah, if u could that would
Yeah, if u could that would b great. I'd like 2 see ur implimentation, did u add any mystical bits? I basically just cloned the calendar view & made it specific 2 a group with only their date nodes & access. Was pretty painless, I'm still going to try out the pannels bit I think, cause I like the setup on the link above. I appriciate ur offer!
Cheers!
Below is the date+calendar functionality
Below is the date+calendar functionality I setup with just views relationships. You'll need a field_date in cck for it to work properly. Basically all it does for the blocks is use relationships based on group post, this method can be also used to create anything relating to a group like group links,locations,faq etc.. The view below overrides the default calendar view, so just disable it or change the path to something else.
$view = new view;$view->name = 'ogcalendar';
$view->description = 'A multi-dimensional calendar view with back/next navigation for Groups.';
$view->tag = 'GroupCalendar';
$view->view_php = '';
$view->base_table = 'node';
$view->is_cacheable = FALSE;
$view->api_version = 2;
$view->disabled = FALSE; /* Edit this to true to make a default view disabled initially */
$handler = $view->new_display('default', 'Defaults', 'default');
$handler->override_option('relationships', array(
'group_nid' => array(
'label' => 'Group node (post)',
'required' => 1,
'id' => 'group_nid',
'table' => 'og_ancestry',
'field' => 'group_nid',
'relationship' => 'none',
),
));
$handler->override_option('fields', array(
'title' => array(
'label' => '',
'link_to_node' => 1,
'exclude' => 0,
'id' => 'title',
'field' => 'title',
'table' => 'node',
'relationship' => 'none',
),
'changed' => array(
'label' => '',
'link_to_node' => 0,
'exclude' => 0,
'id' => 'changed',
'field' => 'changed',
'table' => 'node',
'relationship' => 'none',
'date_format' => 'small',
),
));
$handler->override_option('sorts', array(
'changed' => array(
'order' => 'ASC',
'delta' => '-1',
'id' => 'changed',
'table' => 'node',
'field' => 'changed',
'relationship' => 'none',
),
'field_date_value' => array(
'order' => 'ASC',
'delta' => '-1',
'id' => 'field_date_value',
'table' => 'node_data_field_date',
'field' => 'field_date_value',
'relationship' => 'none',
),
));
$handler->override_option('arguments', array(
'group_nid' => array(
'default_action' => 'default',
'style_plugin' => 'default_summary',
'style_options' => array(),
'wildcard' => 'all',
'wildcard_substitution' => 'All',
'title' => '',
'default_argument_type' => 'node',
'default_argument' => '',
'validate_type' => 'none',
'validate_fail' => 'not found',
'break_phrase' => 0,
'not' => 0,
'id' => 'group_nid',
'table' => 'og_ancestry',
'field' => 'group_nid',
'validate_user_argument_type' => 'uid',
'validate_user_roles' => array(
'2' => 0,
'3' => 0,
'5' => 0,
'4' => 0,
),
'relationship' => 'none',
'default_options_div_prefix' => '',
'default_argument_user' => 0,
'default_argument_fixed' => '',
'default_argument_php' => '',
'validate_argument_node_type' => array(
'blog' => 0,
'poll' => 0,
'drigg' => 0,
'panel' => 0,
'book' => 0,
'calendar' => 0,
'embedded_media_feeds' => 0,
'em_rss_feeds' => 0,
'genlinks' => 0,
'gentoo_info' => 0,
'gen_gallery' => 0,
'gen_image' => 0,
'group' => 0,
'group_post' => 0,
'page' => 0,
'rss_feed' => 0,
'rss_media' => 0,
'simplenews' => 0,
'story' => 0,
'uprofile' => 0,
'work_info' => 0,
),
'validate_argument_node_access' => 0,
'validate_argument_nid_type' => 'nid',
'validate_argument_vocabulary' => array(
'14' => 0,
'9' => 0,
'8' => 0,
'16' => 0,
'17' => 0,
'18' => 0,
'4' => 0,
'5' => 0,
'11' => 0,
'3' => 0,
'2' => 0,
'6' => 0,
'13' => 0,
),
'validate_argument_type' => 'tid',
'validate_argument_transform' => 0,
'validate_user_restrict_roles' => 0,
'validate_argument_node_flag_name' => '*relationship*',
'validate_argument_node_flag_test' => 'flaggable',
'validate_argument_node_flag_id_type' => 'id',
'validate_argument_user_flag_name' => '*relationship*',
'validate_argument_user_flag_test' => 'flaggable',
'validate_argument_user_flag_id_type' => 'id',
'validate_argument_is_member' => 0,
'validate_argument_signup_status' => 'any',
'validate_argument_signup_node_access' => 0,
'validate_argument_php' => '',
),
'date_argument' => array(
'default_action' => 'default',
'style_plugin' => 'default_summary',
'style_options' => array(),
'wildcard' => 'all',
'wildcard_substitution' => 'All',
'title' => '',
'default_argument_type' => 'date',
'default_argument' => '',
'validate_type' => 'none',
'validate_fail' => 'not found',
'date_fields' => array(
'node_data_field_date.field_date_value' => 'node_data_field_date.field_date_value',
),
'year_range' => '-3:+3',
'date_method' => 'OR',
'granularity' => 'month',
'id' => 'date_argument',
'table' => 'node',
'field' => 'date_argument',
'relationship' => 'none',
'default_argument_user' => 0,
'default_argument_fixed' => '',
'default_argument_php' => '',
'validate_argument_node_type' => array(
'blog' => 0,
'poll' => 0,
'drigg' => 0,
'panel' => 0,
'book' => 0,
'calendar' => 0,
'embedded_media_feeds' => 0,
'em_rss_feeds' => 0,
'genlinks' => 0,
'gentoo_info' => 0,
'gen_gallery' => 0,
'gen_image' => 0,
'group' => 0,
'group_post' => 0,
'page' => 0,
'rss_feed' => 0,
'rss_media' => 0,
'simplenews' => 0,
'story' => 0,
'uprofile' => 0,
'work_info' => 0,
),
'validate_argument_node_access' => 0,
'validate_argument_nid_type' => 'nid',
'validate_argument_vocabulary' => array(
'14' => 0,
'9' => 0,
'8' => 0,
'16' => 0,
'17' => 0,
'18' => 0,
'4' => 0,
'5' => 0,
'11' => 0,
'3' => 0,
'2' => 0,
'6' => 0,
'13' => 0,
),
'validate_argument_type' => 'tid',
'validate_argument_php' => '',
'override' => array(
'button' => 'Override',
),
'default_options_div_prefix' => '',
'validate_user_argument_type' => 'uid',
'validate_user_roles' => array(
'2' => 0,
'3' => 0,
'5' => 0,
'4' => 0,
),
'validate_argument_transform' => 0,
'validate_user_restrict_roles' => 0,
'validate_argument_node_flag_name' => '*relationship*',
'validate_argument_node_flag_test' => 'flaggable',
'validate_argument_node_flag_id_type' => 'id',
'validate_argument_user_flag_name' => '*relationship*',
'validate_argument_user_flag_test' => 'flaggable',
'validate_argument_user_flag_id_type' => 'id',
'validate_argument_is_member' => 0,
'validate_argument_signup_status' => 'any',
'validate_argument_signup_node_access' => 0,
),
));
$handler->override_option('filters', array(
'status' => array(
'operator' => '=',
'value' => 1,
'group' => '0',
'exposed' => FALSE,
'expose' => array(
'operator' => FALSE,
'label' => '',
),
'id' => 'status',
'table' => 'node',
'field' => 'status',
'relationship' => 'none',
),
'type' => array(
'operator' => 'in',
'value' => array(
'calendar' => 'calendar',
),
'group' => '0',
'exposed' => FALSE,
'expose' => array(
'operator' => FALSE,
'label' => '',
),
'id' => 'type',
'table' => 'node',
'field' => 'type',
'relationship' => 'none',
),
'uid' => array(
'operator' => '=',
'value' => '0',
'group' => '0',
'exposed' => FALSE,
'expose' => array(
'operator' => FALSE,
'label' => '',
),
'id' => 'uid',
'table' => 'og_uid',
'field' => 'uid',
'relationship' => 'group_nid',
),
));
$handler->override_option('access', array(
'type' => 'none',
'role' => array(),
'perm' => '',
));
$handler->override_option('title', 'Calendar');
$handler->override_option('header_empty', 1);
$handler->override_option('items_per_page', 0);
$handler->override_option('use_more', 0);
$handler->override_option('link_display', 'calendar_1');
$handler->override_option('style_plugin', 'calendar_nav');
$handler = $view->new_display('calendar', 'Calendar page', 'calendar_1');
$handler->override_option('path', 'calendar');
$handler->override_option('menu', array(
'type' => 'none',
'title' => '',
'description' => '',
'weight' => 0,
'name' => 'navigation',
));
$handler->override_option('tab_options', array(
'type' => 'none',
'title' => '',
'description' => '',
'weight' => 0,
));
$handler->override_option('calendar_colors', array(
'0' => array(),
));
$handler->override_option('calendar_colors_vocabulary', array());
$handler->override_option('calendar_colors_taxonomy', array());
$handler->override_option('calendar_popup', 0);
$handler->override_option('calendar_date_link', '');
$handler = $view->new_display('calendar_block', 'Calendar block', 'calendar_block_1');
$handler->override_option('block_description', 'Group Calendar');
$handler->override_option('block_caching', -1);
$handler = $view->new_display('calendar_period', 'Year view', 'calendar_period_1');
$handler->override_option('style_plugin', 'calendar_style');
$handler->override_option('style_options', array(
'display_type' => 'year',
'name_size' => 1,
'max_items' => 0,
));
$handler->override_option('attachment_position', 'after');
$handler->override_option('inherit_arguments', TRUE);
$handler->override_option('inherit_exposed_filters', TRUE);
$handler->override_option('displays', array(
'calendar_1' => 'calendar_1',
'default' => 0,
'calendar_block_1' => 0,
));
$handler->override_option('calendar_type', 'year');
$handler = $view->new_display('calendar_period', 'Month view', 'calendar_period_2');
$handler->override_option('style_plugin', 'calendar_style');
$handler->override_option('style_options', array(
'display_type' => 'month',
'name_size' => '99',
'with_weekno' => '1',
'date_fields' => NULL,
'max_items' => 0,
));
$handler->override_option('attachment_position', 'after');
$handler->override_option('inherit_arguments', TRUE);
$handler->override_option('inherit_exposed_filters', TRUE);
$handler->override_option('displays', array(
'calendar_1' => 'calendar_1',
'default' => 0,
'calendar_block_1' => 0,
));
$handler->override_option('calendar_type', 'month');
$handler = $view->new_display('calendar_period', 'Day view', 'calendar_period_3');
$handler->override_option('style_plugin', 'calendar_style');
$handler->override_option('style_options', array(
'name_size' => '99',
'with_weekno' => 0,
'max_items' => 0,
'max_items_behavior' => 'more',
'groupby_times' => 'hour',
'groupby_times_custom' => '',
'groupby_field' => '',
));
$handler->override_option('attachment_position', 'after');
$handler->override_option('inherit_arguments', TRUE);
$handler->override_option('inherit_exposed_filters', TRUE);
$handler->override_option('displays', array(
'calendar_1' => 'calendar_1',
'default' => 0,
'calendar_block_1' => 0,
));
$handler->override_option('calendar_type', 'day');
$handler = $view->new_display('calendar_period', 'Week view', 'calendar_period_4');
$handler->override_option('style_plugin', 'calendar_style');
$handler->override_option('style_options', array(
'name_size' => '99',
'with_weekno' => 0,
'max_items' => 0,
'max_items_behavior' => 'more',
'groupby_times' => 'hour',
'groupby_times_custom' => '',
'groupby_field' => '',
));
$handler->override_option('attachment_position', 'after');
$handler->override_option('inherit_arguments', TRUE);
$handler->override_option('inherit_exposed_filters', TRUE);
$handler->override_option('displays', array(
'calendar_1' => 'calendar_1',
'default' => 0,
'calendar_block_1' => 0,
));
$handler->override_option('calendar_type', 'week');
$handler = $view->new_display('calendar_period', 'Block view', 'calendar_period_5');
$handler->override_option('style_plugin', 'calendar_style');
$handler->override_option('style_options', array(
'display_type' => 'month',
'name_size' => '1',
));
$handler->override_option('attachment_position', 'after');
$handler->override_option('inherit_arguments', TRUE);
$handler->override_option('inherit_exposed_filters', TRUE);
$handler->override_option('displays', array(
'calendar_1' => 0,
'default' => 0,
'calendar_block_1' => 'calendar_block_1',
));
$handler->override_option('calendar_type', 'month');
$handler = $view->new_display('calendar_ical', 'iCal feed', 'calendar_ical_1');
$handler->override_option('arguments', array());
$handler->override_option('filters', array(
'status' => array(
'operator' => '=',
'value' => 1,
'group' => '0',
'exposed' => FALSE,
'expose' => array(
'operator' => FALSE,
'label' => '',
),
'id' => 'status',
'table' => 'node',
'field' => 'status',
'relationship' => 'none',
),
'date_filter' => array(
'operator' => '>=',
'value' => array(
'value' => NULL,
'min' => NULL,
'max' => NULL,
'default_date' => 'now',
'default_to_date' => '',
),
'group' => '0',
'exposed' => FALSE,
'expose' => array(
'operator' => FALSE,
'label' => '',
),
'date_fields' => array(
'node.changed' => 'node.changed',
),
'granularity' => 'day',
'form_type' => 'date_select',
'default_date' => 'now',
'default_to_date' => '',
'id' => 'date_filter',
'table' => 'node',
'field' => 'date_filter',
'override' => array(
'button' => 'Use default',
),
'relationship' => 'none',
),
));
$handler->override_option('style_plugin', 'ical');
$handler->override_option('style_options', array(
'mission_description' => FALSE,
'description' => '',
'summary_field' => 'node_title',
'description_field' => '',
'location_field' => '',
));
$handler->override_option('row_plugin', '');
$handler->override_option('path', 'calendar/ical');
$handler->override_option('menu', array(
'type' => 'none',
'title' => '',
'description' => '',
'weight' => 0,
'name' => 'navigation',
));
$handler->override_option('tab_options', array(
'type' => 'none',
'title' => '',
'description' => '',
'weight' => 0,
));
$handler->override_option('displays', array(
'calendar_1' => 'calendar_1',
'default' => 0,
'calendar_block_1' => 'calendar_block_1',
));
$handler->override_option('sitename_title', FALSE);
$handler = $view->new_display('block', 'Upcoming', 'block_1');
$handler->override_option('fields', array(
'title' => array(
'label' => '',
'link_to_node' => 1,
'exclude' => 0,
'id' => 'title',
'field' => 'title',
'table' => 'node',
'relationship' => 'none',
'format' => 'default',
),
'field_date_value' => array(
'label' => 'Date',
'alter' => array(
'alter_text' => 0,
'text' => '',
'make_link' => 0,
'path' => '',
'alt' => '',
'prefix' => '',
'suffix' => '',
'help' => '',
'trim' => 0,
'max_length' => '',
'word_boundary' => 1,
'ellipsis' => 1,
'strip_tags' => 0,
'html' => 0,
),
'link_to_node' => 0,
'label_type' => 'widget',
'format' => 'short',
'multiple' => array(
'multiple_number' => '',
'multiple_from' => '',
'multiple_to' => '',
'group' => 1,
),
'repeat' => array(
'show_repeat_rule' => 'hide',
),
'fromto' => array(
'fromto' => 'both',
),
'exclude' => 0,
'id' => 'field_date_value',
'table' => 'node_data_field_date',
'field' => 'field_date_value',
'override' => array(
'button' => 'Use default',
),
'relationship' => 'none',
),
));
$handler->override_option('title', 'Upcoming');
$handler->override_option('items_per_page', 5);
$handler->override_option('use_more', 1);
$handler->override_option('style_plugin', 'list');
$handler->override_option('style_options', array(
'grouping' => '',
'type' => 'ul',
));
$handler->override_option('block_description', 'Upcoming Group Events');
$handler->override_option('block_caching', -1);
bending technology to fit businesses.
User posting to a calendar
I'm interested to know if a user who visits your site can post an event to the calendar. I have my module working so that the admin can, but I need the user to be able to do this. Would I be in the right place to find out about this?
Calendar screencast
Just wanted to leave a comment on this thread for anyone with questions about using Calendar module. When I first took a look at it, I didn't know the difference between all the date types and what I needed to do to get it going for my setup.
You can find the Drupal Calendar video here.
GotDrupal.com
Sharing what I know via Drupal Videos
GotDrupal.com
Sharing what I know via Drupal Videos
Repeating dates redux
I've got the latest (now Feb. 2010) non-Dev versions of 6.x Date, CCK, Event & Calendar modules, so I guess nothing's been done on creating separate nodes for repeating dates in Calendar view using Event.
Take a look at an example of WebCalendar (php, but not a Drupal module), if you want to see how repeats shoould show up on all applicable dates from only one Entry. I'd like to see Calendar and Event work this way.
http://okshuswapgreens.ca/calendar/month.php?year=2010&month=02
Look at "Organic Winter Produce"
An original entry, for the Wednesdays, is at
http://okshuswapgreens.ca/calendar/view_entry.php?id=796&date=20100203
Repeating Events in Calendar
…is there a way to do this?
One more thing about WebCalendar
I'm trying to phase out the use of WebCalendar by integrating the functionality in drupal - does anyone have any ideas on how to duplicate the email reminder functionality contained in WebCalendar?
If you're not familiar with the application, it sends an email reminder based on either:
The date of the event, an offset of that date (x minutes before/after) and let's you specify a repeat attribute (repeat x times or repeat every x days/hours/minutes)
Any thoughts would be appreciated.
Keith
WebCalendar to Drupal
I've just been finding out (I believe) that you may also have to give up the functionality of WebCalendar's REPEATS feature, which, unlike Event and Calendar in Drupal (I believe), displays repeats on the days they occur. Repeats are displayed only on the first day of the event series in Drupal, (unless individually entered).
Sorry, I can't help you on the reminder thing.
Russ.
perl to the rescue
Thanks Russ, I did manage to find someone using a perl script to do something almost identical. It was an old post, I think it was built for drupal 4.x. The script was so simple, that it made me realize that all I needed to do was convert the webcalendar cron job to be compatible with drupal events. I'll post the script (when complete) if anyone is interested.
Keith
script for reminders
definitely interested.
Russ.