Parameters for Custom Post Type: Event

[chipbennett]

So, working from my previous thread, I wanted to start brainstorming a Custom Post Type "Events" would look, and what would comprise its data. Here are my initial thoughts. Please add yours, as well. If I go this route, I want to code it as correct and complete as possible, the first time.

--------------------------------------------------------------
Post Type: Events
- Event Title
- Event Description
- Event Author
- Event Date Range
-- Single
--- Event Date
-- Multiple
--- Event Start Date
--- Event End Date
- Event Duration
-- All Day
-- Periodic
--- Start Time
--- End Time
- Event Recurrence
-- None
-- Recurring
--- Recurrence End Date (or Duration: X [time period])
---- Daily
---- Weekly
----- Day of Week
---- Monthly (Quarterly, Bi-Annually, Annually, etc.)
----- Day of Month
----- Nth Weekday
- Event Cost
- Event Attendance
-- Max Attendees
-- Min Attendees

--------------------------------------------------------------
Taxonomy: Events
- Event Category
- Ministry Type (special use case for my needs: building a church calendar)

------------------------------------------------------------------------

So, that's what I've come up with so far. Can anyone think of anything else?

(Note: first, I'm trying to tackle what data/information I need to define for each event; next, I'll worry about ho to massage those data into an actual calendar. First things first, though.)

[Otto]

General thoughts, not all of which are immediately relevant to the specific questions above, and some of which you will probably find obvious.

- Type should be "event". Each entry represents a single event. I'm a stickler for correct plurals.

- Anything that you can fit into the posts table that makes sense should be there in a way that makes sense. "Description" for example, would go into post_content. Anything else should be stored with the post as post_meta.

- Anything you store as post meta should be int he most standard form possible. "Date" should be a unix timestamp, for example. Leave formatting to the code, store the data as raw data.

- Combine things. A lot of the date stuff you listed should be stored in the same fields.

- When making meta key names, use a prefix for all entries. It will save your sanity later.

- Use the post_date in the post as the start date, or whatever the earliest entry is. Retrieving data by meta is slightly difficult, might help to make your calendar building easier. However, duplicate that date as meta data too.

[sleary]

The trick with using the post_date as the start date is that you'll probably want to display the event before it occurs, so you'll need to do some fiddling with the way WP handles scheduled posts.

[chipbennett]

So, both @_mfields and @ryancduff have offered to help/collaborate on making a robust "Event" custom post type (semantically correct pluralization just for you, Otto ;) ).

Also, @prettyboymp has offered some of his own custom code as a starting point/aid: http://bit.ly/anZGD4 (pastebin link).

More later...

[chipbennett]

General thoughts, not all of which are immediately relevant to the specific questions above, and some of which you will probably find obvious.

- Type should be "event". Each entry represents a single event. I'm a stickler for correct plurals.

Yep; should have been more careful there.

- Anything that you can fit into the posts table that makes sense should be there in a way that makes sense. "Description" for example, would go into post_content. Anything else should be stored with the post as post_meta.

Absolutely! I figured (Post) Title and Content would be used here.

- Anything you store as post meta should be int he most standard form possible. "Date" should be a unix timestamp, for example. Leave formatting to the code, store the data as raw data.

Will keep that in mind. I hadn't thought that far ahead yet.

- Combine things. A lot of the date stuff you listed should be stored in the same fields.

What do you see that can be combined? I want to be thorough, but not repetitive.

- When making meta key names, use a prefix for all entries. It will save your sanity later.

Will keep that in mind. I hadn't thought that far ahead yet.

- Use the post_date in the post as the start date, or whatever the earliest entry is. Retrieving data by meta is slightly difficult, might help to make your calendar building easier. However, duplicate that date as meta data too.

I'm not sure. I think post_date should be the date that the event is published, not the date that the event occurs. I see post_date for post-type "event" being pretty similar to post_date for post-type "page" - i.e. not terribly relevant to the content of the post.

[prettyboymp]

I'm not sure. I think post_date should be the date that the event is published, not the date that the event occurs. I see post_date for post-type "event" being pretty similar to post_date for post-type "page" - i.e. not terribly relevant to the content of the post.

I agree with Otto on this. If you don't use the post_date, for the start date, you'll run into performance issues since you won't have the index you need on the dates if there in post meta.

[chipbennett]

I agree with Otto on this. If you don't use the post_date, for the start date, you'll run into performance issues since you won't have the index you need on the dates if there in post meta.

But how do those performance issues compare with messing with the default handling of displaying posts - especially with respect to "future" posts (as most event-type posts will be)?

Also, I would imagine that the most common use case would be displaying event-type posts:

1) using single.php (detail view)
2) as a list (simple list, or typical "calendar" layout, showing post_title only)

I don't think displaying event-type posts in the same manner as post-type posts (sub-optimal eloquence, that - but I digress) will be a very common use-case.

[mfields]

I agree with Chip that that the post_date field should store the date that the post was created. Semantically, this just makes sense to me. Onr thing that I have always wondered but never really tried is to add my own fields to the posts table. In this scenario, there could be start_time and end_time. I realize that this will add a bit of bloat to the table for non-event posts, but would solve some of the issues using custom fields. Till this days I still cannot figure out how to query for "An event that is happening right now" while storing start_time and end_time as custom fields. Getting back to the topic of adding your own fields to the post table... is this a bad practice? Will this mess with upgrades? Just a thought.

[bglaettli]

So, working from my previous thread, I wanted to start brainstorming a Custom Post Type "Events" would look, and what would comprise its data. Here are my initial thoughts. Please add yours, as well. If I go this route, I want to code it as correct and complete as possible, the first time.
------------------------------------------------------------------------

(...)
So, that's what I've come up with so far. Can anyone think of anything else?

Before re-inventing the weel, I would definitly recommend you to check out the iCalendar standard and base your work on this standard. This would later faciliate to add import/export features to your plugin, if you should wish to do so:
http://en.wikipedia.org/wiki/ICalendar
http://tools.ietf.org/html/rfc5545

When formatting the output, you might consider using the hCalendar Microformat Markup: http://en.wikipedia.org/wiki/HCalendar

[chipbennett]

Before re-inventing the weel, I would definitly recommend you to check out the iCalendar standard and base your work on this standard. This would later faciliate to add import/export features to your plugin, if you should wish to do so:
http://en.wikipedia.org/wiki/ICalendar
http://tools.ietf.org/html/rfc5545

When formatting the output, you might consider using the hCalendar Microformat Markup: http://en.wikipedia.org/wiki/HCalendar

Great suggestions! I definitely intended for the Event post-type to be compatible with iCal.