[EventCalendar] Custom query to sort by date, Many events per post
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
> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the EventCalendar