[EventCalendar] Custom query to sort by date, Many events per post

David Garlitz dgarlitz at wesleyan.edu
Wed Feb 20 14:28:17 UTC 2008

Hi Mathew - Can you give me some more details on your quick hack for  
a custom query to sort by start date? I follow you on the overall  
concept, but my php skills are not well honed enough to improvise the  
hack on my own...

Thanks a lot!

> Is there a preferred way of doing a custom query to
> sort by start time?  I couldn't find any such way, so
> I wrote a quick hack to set a global variable
> "$ec3_temporary_hack = 1" when I want the results of a
> query_posts to be sorted by event order.  I then added
> a check to eventcalendar3's "posts_where" filter
> function to check for my temporary hack variable.  If
> it is set, it does "$ec3->order_by_start=true;
> $ec3->join_ec3_sch=true;"  It's an ugly hack, but it
> works until I find a better way to do it.
> If there is no such way, what would be the preferred
> way to implement it?  In this case, I could submit a
> patch with a proper implementation to keep other
> people from having to use similar hacks.
> Also, there should be a clean way of doing one post
> with many event instances.  For example, an event
> might repeat itself every week, in which case one post
> might have 52 events.  Right now, every single event
> instance is listed on the post page, which is quite
> ugly.  Which of these options would be preferable:
> 1) On the post itself, only display the next N
> upcoming instances of the event.  (I am referring to
> the actual post, not the calendar view)  If there are
> no upcoming instances, display most recent N instances
> of the event.  If there are fewer than N instances of
> the event, always display all the times.
> Example (N=4): Event XYZ: [November 22 @ 6:00pm,
> November 29 @ 6:00pm, December 6 @ 6:00pm, December 13
> @ 6:00pm]
> 2) Same as above, only display the first N event
> instances that are either upcoming *or* from the
> current month.  If there are no upcoming event
> instances, display the most recent N instances.  If
> there are fewer than N instances of the event, always
> display all the times.
> Example (N=4): Event XYZ: [November 1 @ 6:00pm,
> November 8 @ 6:00pm, November 22 @ 6:00pm, November 29
> @ 6:00pm]
> 3) Some variant of the above ideas.
> 4) In addition to one of the previous ideas, implement
> new UI features to allow true recurring events to be
> specified, with start and end dates.  For example, an
> event might last from Jan 1, 2007 to Jan 1, 2009 -
> repeating every Thursday at 6:00pm.  A method (such as
> one I suggested above) would be used to pick which
> dates to display.  If the you like this option, what
> type of interface would you like to see to add these
> events?  Also, how should this be stored in the
> database?  (The table format would need to be changed)
> Example (N=4): Event XYZ: [Weekly, Thursday at 6:00pm.
> Upcoming times: November 22 @ 6:00pm, November 29 @
> 6:00pm, December 6 @ 6:00pm, December 13 @ 6:00pm]
> This latter option would of course be the most
> complex, requiring database changes, user interface
> changes, display changes, and (multilingual) string
> changes.  I might add a "recurrence" column to the
> ec3_events table to specify how often the event should
> occur.  Legacy versions of ec3 would simply interpret
> the recurring event as one event lasting the entire
> duration of the occurrences, ensuring backwards
> compatibility.
> Let me know any implementation ideas or user interface
> ideas you have.  For example what patterns besides
> day-of-week might you want to match on, and how would
> you want to configure it in the user interface?
> (Examples: first four Thursdays each month - with no
> event on Thanksgiving, every other Thursday, first
> Monday of every month, first day of every month, etc)
> Also, would you want these changes separated from my
> big calendar patch, or would it be easier if I keep
> everything in one patch?
> I am putting new non-core features ("post tags", event
> registration) in a new extension, which I haven't
> finished yet.  It will make no direct database calls,
> instead relying on custom queries and eventcalendar3
> built-in functions for everything.  The changes I have
> described in this post are core changes, and thus they
> wouldn't be good candidates for my add-on extension.
> -Matthew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://penguin.firetree.net/pipermail/eventcalendar/attachments/20080220/dcdc430b/attachment.htm

More information about the EventCalendar mailing list