Setup and ICal tabs on every node when using URL node/$group/calendar

I had applied the patch you supplied for Views and still had the problem until I added the if statement above to calendar_menu() and calendar_ical_menu(). Did I miss something from http://drupal.org/node/136968?

Thanks again!

I did some more testing and I don't think this is a Views problem, but rather has more to do with the menu system's handling of MENU_LOCAL_TASK's.

So, if in node/$group/calendar, $group is a valid group id, then Views has already registered the right URL and everything works fine.

The committed version of calendar_menu() and calendar_ical_menu(), however, always register node/$group/calendar/setup and node/$group/calendar/ical, regardless of whether $group is a valid group id or not.

If $group is only a valid nid and not a valid group id, then Views didn't register node/$group/calendar, and the system assumes that 'Setup' (with URL node/$group/calendar/setup) is just a task of node/$group the same way as Edit (with URL node/$group/edit).

So there needs to be a way in calendar_menu() and calendar_ical_menu() to check if $group is valid. The code I posted yesterday sort of works, but not exactly, so rather than doing that, I added a line in the foreach($parts) statement:

      foreach ($parts as $delta => $part) {
         if ($part == '$group' && !og_url_group($part, '', arg($delta))) return $items; //see if $group is a group
         if (in_array($part, array('$arg', '$node', '$user', '$group'))) {
            $parts[$delta] = arg($delta);
         }
      }

If I'm wrong about a problem here or if there is a better way to check if $group is valid, please let me know. Thanks!

Hi, just wanted to check back on this issue.

I've been using the OG that has $group handling since I've had the problem along with the latest Views. I'm not sure exactly how to clear the menu cache, but every other menu works fine.

I'm still convinced that this is in the calendar_menu() function. The code to create the menu item gets called on every page, dynamically creating it each time.

The line foreach (calendar_info() as $view_name => $view) {
correctly finds the view/calendar with the URL node/$group/calendar.

The URL node/$group/calendar gets broken up into $parts, which then each $part is checked to see if it's $group, which the second one is.

So the line $parts[$delta] = arg($delta);
sets $parts[$delta] to whatever value happens to be returned by arg($delta).

So then in a few lines later, if we happen to be on node/3 for example,
'path' => implode('/', $parts) .'/setup',
sets the path to node/3/calendar/setup and creates the menu item regardless of whether node/3 is a group node.

As I said above, if node/3 is a group node, then Views has already registered node/3/calendar as a URL using the code from OG, and so node/3/calendar/setup is a child of node/3/calendar, which is a calendar, and everything works beautifully.

If node/3 is not a group page, then node/3/calendar doesn't exist. node/3/calendar/setup is still registered, however, but this time as a child of node/3, which is why the 'Setup' tab shows up even though node/3 is not a calendar.

So, the line I added back in the earlier post
if ($part == '$group' && !og_url_group($part, '', arg($delta))) return $items;
checks to see if arg($delta) is a valid group id or not using the function in OG that Views uses. If it is a group page, then it continues to build the URL. If not it returns before the URL gets registered.

Whether that's the best way to do it or not, I don't know. But arg($delta) needs to be checked as a valid group id before a menu is built.

Thanks!

I cleared the entries in the cache_menu MYSQL table and the Setup tab still appears without the modifications I mentioned above.

Really, since the code in calendar_menu() is surrounded by if (!$may_cache) {}, I don't think caching would be the problem here, anyway, would it?

Thanks again!

Any news on this item? Thanks!

Karen,

I tried all of this with a fresh installation of Drupal 5.2 with clean URL's, the dev versions of Calendar (2007-Dec-02) and Date (2007-Dec-03), and the latest OG (5.x-4.1 2007-Dec-02) and Views (5.x-1.6 2007-Jul-14) with the patch.

I added the the content type 'group' and set it to use the group home page.

I added a default calendar view by clicking 'add' and a group calendar view with the url node/$group/calendar with the first argument set to an OG group nid with the additional calendar arguments. I set the page to have a menu item as a tab.

I created 1 group and 1 normal page (node/2). The Setup and ICal tabs, however, still show up on the normal page. On actual group pages, everything works fine because the tabs are moved down to the group calendar page.

Every time I look at the current code for calendar_menu(), it seems completely logical to me why they are showing up in unwanted places. calendar_menu gets called on every page, not just calendar pages. Then, calendar_info() in the foreach statement returns all the calendar views, which in my case, 2 of them with URL's of 'calendar' and 'node/$group/calendar'. Both URL's are parsed and for node/$group/calendar, $group is replaced with the nid of whatever the current page is, and then a menu item is created for it, regardless of whether node/2 is a group or not.

function calendar_menu($may_cache) {
  $items = array();
  if (!$may_cache) {
    include_once('./'. drupal_get_path('module', 'calendar') .'/calendar.theme');
    drupal_add_css(drupal_get_path('module', 'calendar') .'/calendar.css');
    define('CALENDAR_EMPTY_ARG', variable_get('calendar_empty_arg', 'all'));
    foreach (calendar_info() as $view_name => $view) {
      $parts = explode('/', $view['url']);
      foreach ($parts as $delta => $part) {
        if (in_array($part, array('$arg', '$node', '$user', '$group'))) {
          $parts[$delta] = arg($delta);
        }
      }
      $items[] = array(
        'path'     => implode('/', $parts) .'/setup',
        'title'    => t('Setup'),
        'description' => t('Calendar setup.'),
        'access'   => user_access('administer views'),
        'callback' => 'drupal_get_form',
        'callback arguments' => array('calendar_setup_form', $view_name),
        'type' => MENU_LOCAL_TASK,
        'weight' => 5,
      );
    }
  }
  return $items;
}

The only way it would not put Setup tabs on every page with a URL of node/nid is if calendar_menu was not called except on calendar pages. If my logic is wrong, please let me know!

Thanks again for all your help!

Should calendar_info() return something like node/3/calendar in $view['url'] instead of node/$group/calendar? Based off of the parsing of $parts I've been assuming node/$group/calendar

Thanks again!

I don't know if I missed something or not, but I'm still having this problem without the modifications to calendar_menu() I mentioned above. Also, as I said before, it makes perfect sense to me why the Setup tabs appear on every non-group node with the current version of the function.

Thanks!

Don't mean to be a bother, but I'm still having this issue unless some sort of check to make sure $group is a valid gid.

Using fresh install of Drupal 5.5 with

Calendar 5.x-1.x-dev 2007-Dec-15
OG 5.x-4.3 2007-Dec-19
Date 5.x-1.x-dev 2007-Dec-10
Views 5.x-1.6 2007-Jul-14 with patch from http://drupal.org/node/183191

The default calendar view is overidden but without changes.
I've created another view with the URL of node/$group/calendar and set the menu item to be a tab. Its first argument is set to OG: Group nid(s), with the calendar arguments following.

The tabs go away with code to validate $group.

Thanks!