OG Views Calendar - tab and block - making it work.

Using a $view->url of 'node/$node-class/calendar' and tabs, I provide a Calendar tab on node/$node-class. $node- is I believe an undocumented Views feature that works like $node, but for a specific content type -- keeping the Calendar tab from appearing for other content types.

Views Argument

To get the calendar tab to work properly, I have to use this custom Views Argument:

$date = getdate(time());

if(arg(0) == 'node' && is_numeric(arg(1))):
  $og_context = og_get_group_context();
  if ($og_context->nid == arg(1)) $gid = $og_context->nid;
  if (!$gid):
    $viewnode = node_load(array('nid' => arg(1)));
    $viewtype = $viewnode->type;
    if ($viewtype == 'classtrip') $gid = $viewnode->og_groups[0];
  endif;
endif;

$args[0] = $gid;

if (!$args[1]) $args[1] = $date['year'];
if (!$args[2]) $args[2] = $date['month'];
if (!$args[3]) $args[3] = 'all';

return $args;

.. the getdate() essentially simulating the URL of 'node/68338/calendar/2008/03/all' because for some reason, 'node/68338/calendar' alone gives me a calendar, but without events. A bug for a different day.

(The $viewtype .. part checks if the node we are viewing is part of a group and passes the first group there as the argument, so the block can work if we are viewing something owned by the group.)

Block

The block is tricky. This bit of code on line 20 of calendar.inc -- _calendar_views_query_alter, is causing problems:

$view->args = explode('/', str_replace($view->url .'/', '', $_GET['q']));

It's essentially overriding my $args above, including the $gid. I end up with a block calendar with a week view that says something along the lines of "March 8338" where 8338 is the last 4 digits of the group nid.

This line falls under "if ($view->build_type == 'block') {" -- but my feeble mind cannot comprehend why we would want to rely on $_GET['q'] for parsing arguments to a block. If the arguments for the block match $_GET[q], then we are likely viewing the full-size calendar already?

In any case, my solution was to comment this line out. I am setting $view->args in the Views Arguments Code and do not want it overridden without consideration.

Commenting out that line, then applying this fix -- http://drupal.org/node/227443 and the block now displays on node/$node-class and node/$node-classtrip.

Clicking on a date or using the « and » navigators brings me to that date on the full tab, which is fine in my case.

The $node-type dilemma

The last remaining problem I have is with using $node-class.

If I use 'node/$arg/calendar' -- the Calendar tab appears on every node, every content type.
If I use 'node/$node/calendar' -- again, the tab appears on every node, every content type.
If I use 'node/$group/calendar' -- no tabs/page available.
If I use '$group/calendar' -- again, no tabs or page. The block also breaks in this case.

That leaves 'node/$node-class/calendar' -- where 'class' is the content type. The tab only appears on class nodes. The block works.

.. and this brings up a new problem.

Nasty Hacks

All links generated by Views Calendar in the block are broken. They attempt to link to the literal 'node/$node-class/calendar/2008/03/all' -- instead of replacing $node-class with the proper ID.

Some consideration has been made for using node/$node/calendar and such, according to calendar.module:

/**
 * Figure out what the URL of the calendar view we're currently looking at is.
 */
function calendar_real_url($view, $args) {
  // Add non-calendar arguments to the base url.
  $parts = explode('/', $view->url);
  $bump = 0;
  foreach ($parts as $delta => $part) {
    // If one of the args is buried in the url, add it here and adjust
    // the delta values we'll compare the calendar arg positions to.
    if (in_array($part, array('$arg', '$node', '$user', '$group'))) {
      $parts[$delta] = array_shift($args);
      $bump++;
    }
  }
  foreach ($args as $delta => $arg) {
    if (!in_array($delta + $bump, calendar_arg_positions($view)) && !empty($arg)) {
      array_push($parts, $arg);
    }
  }


  return implode('/', $parts);
}

As you can see, this requires modification to support $node-type by any means. In my case, I opted to add $node-class to that array. I could have pulled a list of available content types and checked them all, or used strpos to locate $node and yank that part out of the array, but alas .. I'm not even yet certain if this is the direction I should be heading. I'm just knocking down walls..

Unfortunately, this still doesn't solve the problem entirely. The « prev, next » and iCal links of the calendar block still include the literal '$node-class' in them.

Tracking through iCal reveals what is possibly the problem.

In function calendar_ical_views_feed_argument:

    $args = calendar_ical_post_view_make_args($view, $arg, 'ical');
    $url = views_get_url($view, $args);

    $title = views_get_title($view, 'page', $args);
    if ($view->used_filters) {
      $filters = drupal_query_string_encode($view->used_filters);
    }
    return implode(calendar_ical_add_ical(url($url, $filters), $title));

views_get_url is not aware of $node-host nor $args[0] being the $gid.

The resulting iCal URL ends up looking like:

node/%24node-class/calendar/68338/2008/March/all/ical

Perhaps we should be passing $url or filtering $args through calendar_real_url first.

Out of time for now, I will figure this out tomorrow and post.