Using posts for events
In this page we indicate how posts can be used to create events pages with search engine friendly naming, category filtering and RSS feeds. Using posts for events has the following advantages:
- supports cross referencing of events to other events
- allows the creation of a single events post type then the application of different filter types to display subsets on different pages. Context sensitive events via category filtering
- supports more structured events with configurable fields to relate events posts to product lines, countries or particular locations etc.
- alternate output options are available such as calendars and diary views.
- posts from a Calendar (post) page are indexable in internal searches (added in 11.0)
- easier aggregation of events articles via the use of searchposts 'posttypeid_csv' argument which accepts a comma separated list.
The steps are as follows
- Create a post type that will collect all the information you want to store for each event.
- Create a page that displays the above posts, the examples below show a standard list page however there are ample opportunities for customisation.
In more detail:
Create a post type ‘site wide events’, it would be a good idea to give it a name other than plain 'events' so as not to confuse the post based system with the existing traditional events module.
You can add whatever custom fields you want. A common one to add is a circular reference to the 'site wide events' as a multi-select. This then gives the potential of creating links to related events from other events.
Another common custom events field is 'category'. You can either create this as a text field or reference another new post type with a fixed list of categories. You can then filter on these.
In extranets and intranets, a user group option is also handy as it gives the option to filter events based on the logged in user's group. An example of the events post type set up is shown below:
After creation of the post type the 'site wide events' can be populated from the 'edit' tab as shown below:
A new page is then created with the content type set as 'posts:site wide events'. The resulting default page is shown below:
The above page could be completely customised as with all the post pages by altering the relevant XSLs in the page content section. Similarly the events could be filtered by adding arguments into the 'XML parameters' field. For example the addition of '&custom_category=concert' would then filter the events to only those tagged with a 'concert' category.
Similarly if an events summary listing was required for the sites' front page this could be obtained as a data island using the following as the XML source:
http://<domain>/RSS-Posts.aspx?id=46&maxage=100&striphtml=1&custom_category=concert
Will provide an RSS formatted feed from post type 46 for the last 100 days, tagged with category 'concert' and strip any markup from the body block. This latter argument is handy in case a truncated version of the summary is wanted in the listing.
In terms of indexing. The same post has two pages that could show it but only one has a RESTurl. When the search spider works out the best url to use for the post it priortises the one that has a REST url, so it indexes it under that page. It will get spidered twice but using the same REST url, so only appears once in the index.