Category page

Hey Sven,

Sorry for the delay. This particular feature has been waiting in queue for a while now to get completed. Essentially, I have to add the code to make it happen, and make sure that the code I add is universal enough to work in the places everyone expects, but not so overly aggressive that it happens everywhere, since it is not appropriate everywhere.

Until I manage to get that completely working, I do have a decent work around for this. It is a very basic function that you can stick in your functions.php file in your theme. This function should make it so that all your frontend queries for posts include events. This means that they will show on the category pages, but they will also show on the date archive pages, the home page, etc, etc… It can easily be modified to fit your needs, which I will give some examples of below.

*Basic function (insert in functions.php)*

function qsot_include_events( $q ) {
  // alias the query vars to a shorter variable name (not required)
  $v = $q->query_vars;

  // do not make any changes to the query, if a specific POST
  // has been requested
  if ( isset( $v['name'] ) || isset( $v['p'] ) )
    return $q;

  // do not make any changes to the query, if a specific PAGE
  // has been requested
  if ( isset( $v['pagename'] ) || isset( $v['page_id'] ) )
    return $q;

  // when not in the admin, and processing the main page query
  if ( ! is_admin() && $q->is_main_query() ) {
    if ( ! isset( $v['post_type'] ) ) {
      // if the list of post types was not supplied, then create one
      // that uses 'post' and 'qsot-event' (event post type)
      $v['post_types'] = array( 'post', 'qsot-event' );
    } else {
      // add the event post type to the list of possible post types
      // to query for
      $v['post_type'] = (array)$v['post_type'];
      $v['post_type'][] = 'qsot-event';
    }
  }

  // reassign the query vars back to the long name
  $q->query_vars = $v;

  return $q;
}
add_filter( 'pre_get_posts', 'qsot_include_events', 10, 1 );

The above function will convert all ‘main query’ post queries (the primary query that is done internally by wordpress to determine what to display on the page), into a query that also includes qsot-event, which is the event post type. It will not affect queries that are for specific pages or posts, because those should not be modified. Instead, any main query that requests more than one result (homepage, category, search, etc…) will also include qsot-events.

Now if you want this to only take effect on a specific category, you could easily modify it so that the filtering only takes place on that specific category. Change this if statement:

if ( ! is_admin() && $q->is_main_query() ) {

to something like this:

if ( ! is_admin() && $q->is_main_query() && is_category( 'books' ) ) {

Or if you only want this logic to happen on the homepage, then you can change the same if statement to something like:

if ( ! is_admin() && $q->is_main_query() &&
    ( is_home() || is_front_page() ) ) {

Hopefully this points you down the right path. If you need more specific information on how you can modify the query the codex has a pretty comprehensive page on the wp_query class itself. I find myself referring to it more than any other page in the codex.

Let me know if I can help further,
Loushou

Hey @sventertain,

I have this feature added to the latest release, 1.12.4. I will say that only the ‘parent events’ show here though. The reason for this, is because the category pages are date driven. Since that is the case, the child events have a weird situation where the ‘date’ that makes the most sense to use, does not fit nicely into the category page paradigm.

You see, the category page shows the ‘latest’ posts, in order from today backwards. With a parent event, the date that can be used effectively is the ‘publish date’; however, for child events, this is not that logical. Child events will typically all be published on the same day (usually the same day as the parent event). Thus they will all be crammed into ‘today’, even if the date of the actual event is 3 months from now.

To make matters worse, we cannot really use the ‘event date’ for child events either. The reason is because the category pages actually show from ‘right now’ backwards. Thus if we use the event date to determine which child events to show on the category pages, we will only be showing child events that have already transpired, thereby rendering the whole flow change a moot point.

Instead, we just dropped the idea of using child events in the category page. It makes some sense to add the parent event in there, so I added code for this. It may turn out that we may need to make this an option instead of always on, cause some people may or may not want it…. sooo.

If you need something more complex, you may consider making a page template in your theme that implements your custom logic. For instance, if you wanted a page that listed all of the upcoming events, not in calendar form, you could make a page for that… Alternatively, if that was actually your motivation for the request in the first place, we actually have a plugin called Display Options which adds a d shortcode and a widget to do just that, show a list of upcoming events outside of the calendar. It also allows you to put the tickets into the ‘shop experience’…. food for thought.

Hope this helped,
Loushou