This project has moved and is read-only. For the latest updates, please go here.

New Plugin Released - Events and Event Calendars

Feb 28, 2010 at 9:16 PM

Hey everyone, I've released my latest plugin - allows for Event-type posts and displaying event calendars. The code and plugin DLL are available at http://graffiticmsevents.codeplex.com/. For examples and help getting started using it, you can see my post at: http://www.nexustechnologiesllc.com/blog/event-calendar-for-graffiti-cms/.  Special thanks to David Penton for providing a starting point for me at http://pentonizer.com/csharp/event-calendar-for-graffiticms/.

Mar 10, 2010 at 11:25 PM

Very nice, I'm using it here: http://shc.org.au/about/events/

It has a rather nasty bug which breaks it when the user enters a post which an incorrectly formatted Event Date.

 

 

Mar 11, 2010 at 12:24 AM

That's a bug with the custom fields in Graffiti itself - it isn't doing the validation of Date types that it is supposed to do. See this issue: http://graffiticms.codeplex.com/WorkItem/View.aspx?WorkItemId=11685

Mar 26, 2010 at 12:38 AM

The validation bug has been fixed in the latest build but this may be an issue if you used anything other than firefox to enter dates with a prior build. By default the date in a custom field is formatted with "at" between the date and time. You may need to remove " at" to prevent a problem. To get a valid datetime value via chalk, I've had to use something like this $DateTime.Parse($post.Custom("My Date").replace(" at", "")).

Were you able to datetime parse the custom field with the "at" in there or were you validating values manually? In your source it looks like you dont account for "at" unless somehow Parse is that forgiving, but it sure wasnt for me in chalk.

Since the "at" makes it invalid, I vote to have "at" removed, but I dont know what negative effects this might have on other things people have used custom datetime fields for. DateTimeFormElement.cs is where the problem lies. IMO it should be fixed to match the publish date field.

Mar 30, 2010 at 4:12 AM

I never use that resource hog of a browser unless I absolutely have to (mainly to use firebug), so yes, my usage was always with another browser (Chrome or IE). Since I was never viewing auto-formatted dates, I never had the problem that you were having with the "at", since I was manually entering my dates and times. And actually, I only anecdotally tested putting times in the field, since the plugin has start/end time text fields (to allow for more free-form choices of start and end times, like start at dusk until midnight or something like that).

I agree with you that the "at" should be removed because it really isn't a standard format for date/time, and since there is validation in place (now that it's working), people adding posts should be able to see how it should be entered with a time.

Mar 30, 2010 at 5:04 AM

Great, thats two votes to remove the "at". I see little reason removing it would be a problem since validation was previously broken and to use it as a valid datetime field, you have to remove it anyway, so if kevin or dan think its ok to remove, lets do it.

Nice work on the plugin. Graffiti was in desparate need of something like this.

Mar 30, 2010 at 5:11 AM

Yep, fix it.

+1

Mar 30, 2010 at 6:49 AM
Sounds good to me.
Apr 7, 2010 at 1:26 PM

Nice job with the fix guys.  I just ran up Change Set 45260 and the Events plugin now functions correctly because of the fixes that have been made to Graffiti.

Apr 7, 2010 at 5:22 PM

I'm glad to hear it. I was concerned about this since any values entered in those date time fields prior to change set 42967 could be wiped out when you open the post for editing, and if you saved without re-entering the value, it would be deleted. This is probably unavoidable since there is no way of telling what was entered with the validation broken.

Apr 7, 2010 at 9:16 PM

Ahh you are right actually.  I just went to edit an existing event and, yes, it did wipe out the date value - which caused the Calendar to error.  No big deal, you just need to remember to check that the date exists when you re-save the entry.

Dates!  They always end up getting us developers :-)

Apr 8, 2010 at 5:24 AM

Yeah unfortunately it errors if the datetime field is empty or doesnt exist, or if it contains something not parsable. Now that validation is fixed, i think it just needs to check for the existance of a value since the javascript is taking care of valid datetime format. One wrong move and it completely blows up instead of just skipping that event. I'm guessing it could be simplified with a start datetime and end datetime instead of event date, start time, end time in 3 separate fields. I really need a calendar on one of my graffiti sites and this is the best option I've seen, just needs a small update.

Apr 8, 2010 at 5:52 AM

The plugin cannot do the checking for existence of a value because it is just a custom field and widgets have no control over custom fields. There would need to be an update to Graffiti proper to allow for custom fields to be required, which is a significant change.

The plugin specifically does not have a start datetime and end datetime for a reason - events do not necessarily have a set end time like that and standard text fields for start and end time allow for more unique formatting, when necessary.

You don't actually need to do anything with the plugin to add an end datetime if you want to. All you need to do is add a new custom field and then change your themes to make use of that field on your event pages. All the plugin really does is adds some default custom fields and adds the support for custom URLs and custom widgets, so it is really easy to extend it further if you want to.

Apr 8, 2010 at 6:11 AM
Edited Apr 8, 2010 at 5:41 PM

I see. I was thinking that the start and end times were used somehow in the display of the calendar but if their formatting doesnt matter since they are not used as DateTime values, that makes more sense. So really the only issue is that if there is no event date on an event post, the post needs to be ignored somehow, not to suggest that the field should be required but simply that if you forget to fill it in, there is not a complete failure as a result. Thats why I thought it should check to see if there is a value to try to parse before it even tries, but I was just guessing that it failed there based on the error message I got.

Not the fault of this plugin, but when i enabled it and it created the custom fields for the events category, I got myself into a pickle. I already had an events sub category and since the dashboard doesnt allow you add or remove custom fields on sub categories, the new custom fields are stuck there. I had to change the url to ?category=28 to see the list. Maybe it would be better to list all sub categories as well on Site Options>Custom Fields. It seems you also cannot see sub categories in the list on Navigation Links.

Apr 8, 2010 at 5:53 PM

Tried this just to test, seemed to skip posts without an event date.

 return posts.FindAll(delegate(Post post)
   {
                try
                {
                    DateTime eventDate = DateTime.Parse(post.Custom("Event Date"));
                    return eventDate.Month == month && eventDate.Year == year;
                }
                catch
                {
                    DateTime eventDate = DateTime.MinValue;
                    return eventDate.Month == month && eventDate.Year == year;
                }
               
   });