Synchronicity, event storage and accessing events via the loop

amr events, How To

Synchronicity is the experience of two or more events, that are apparently causally unrelated or unlikely to occur together by chance, that are observed to occur together in a meaningful manner.

Recently within hours of each other I received queries (an email from Chris and a forum post from G470 ) at opposite ends of the spectrum of expectation about recurring events and their storage.    It seems a description of the underlying method of event storage and calculation was necessary for those wanting to do something different.

If you are not up for a detailed technical discussion, do not panic.  Rest assured that the default settings will deliver  commonly accepted ways of seeing events.   The plugin aims to be both simple and customisable.

For the rest read on…..

Chris asked:

Could I just ask how you are handling recurring events? I have seen a number of plugins take a start date and an end date and then just create a whole bunch of database entries for each event in a recurrence, somewhat bloating the database if you have a number of never ending recurring events. Is your way of handling recurring events more sophisticated?

G470 wants recurring events to show up in his normal loop. (Note: the recurring instances, not the original master event).

How are the events stored?

Each event is stored very similarly to the ICS file lines, while attempting to make maximum use of wordpress features and functions.  Each master event (or VEVENT) is one wordpress post (or custom post).  This allows the use of wordpress features, the wordpress query and other plugins with this plugin.  For example, some plugins you may wish to integrate are:

When a recurring ‘master’ event is displayed as a single post, the plugin calculates and displays the future ‘next dates’ – these change all the time as time passes.  Ditto for multiple event listings. See

In the loop?

The master events are displayed or returned  in the loop (if using standard posts or have configured custom posts to display ) sorted by publish date.     Shortcodes are available to list events sorted by their event instance dates.  In addition the function to list the events (amr_list_events) is pluggable, so you can even do your own thing, although generally it will be easier to customise a list type than to write your own whole display routine.

Event instances are themselves not typically displayed ‘in the loop’ for a number of reasons:

  • the loop normally displays posts by dates that have passed – future posted posts are not displayed ‘in advance’.  Events on the other hand, one needs to know in advance.
  • recurring events may result in multiple instances being shown one after another with unnecessary detail.  There are better ways to advise of forthcoming events (widgets, shortcodes, or calling from within a template file (eg: using do_shortcode();)

How are recurring events generated and displayed?

Event instances are displayable via shortcodes either in a page, a widget or within a master event.  The default display assumes that one is only interested in events in the not too distant future from now or from today.

Note: Although unlike Alice in Wonderlands memory which only works backwards, the amr-events plugin can work forwards and backwards, near or far – you can have your jam tomorrow as well as today and yesterday.  See the shortcode parameters for ideas on what you can do.

Thus the recurring logic is done real time for the most appropriate current window of time.  (IE, with respect to the current start date&time and with respect to configurable limits.)

The administrator sets how many days or months to generate for and how many events maximum.   These limits are used at a general/total level and at a specific level to provide some boundary for infinite events.   Administrators should choose limits that make sense for the frequency / density of their events.

The instances are then generated for that ‘window’ of time using some clever logic.

The logic follows the suggested rules found in various ics documentation with respect to ‘expanding’ and ‘contracting’ by the parts of the RRULE.   Needless to say it took a lot of design and coding to get this stable and coping with almost all the possible RRULES.  That part of the plugin has been around for a few years now and was rewritten at least once!

Mapping of WordPress Fields to ICS fields, or additional ‘displayed’ data

ICS => WordPress post

  • SUMMARY => post title
  • DESCRIPTION => post content
  • DTSTAMP => post published date
  • ORGANIZER => post author (may change later, currently NOT issued in ics file produced)

some ICS lines are stored as wordpress META data:

  • DTSTART
  • DURATION (OR DTEND, not both)
  • RRULE
  • EXDATE
  • RDATE
  • LOCATION (depending which location plugin is used)

Additional data:
Some data is generated at display time.  These are usually the ‘instance’ fields:

  • EventDate
  • EventTime
  • EndDate (of instance)
  • EndTime
  • …

Summary

Before feeling that you need to write your own code, please  explore other options

  • see  the variety of list types and the ways that you can customise them before deciding that you need to write your own listing routine.
  • explore other plugins that may integrate well as this plugin was designed to work well with wordpress and the tools that it provides.

This will hopefully save you a lot of time and trouble.