I'm setting this as a support request, but it may just be by design (although I wouldn't recommend it).

It seems like the group context is only set when viewing a group node (node/%), but no where else (ie, node/%/group, /group/node/%/admin/people/*, etc, etc). I haven't yet tested if group context can be set via a View that takes an entity ID argument.

Is that done on purpose? It doesn't make sense to me.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

amitaibu’s picture

Not on purpose, a patch would be great :)

mstef’s picture

I'm still learning the ropes of OG7.x-1.x, especially the og_context module. There's two active context detectors (URL and Node). URL only detects based on URL queries (ie, ?gids[]=), and Node seems to only look for node/% being the active path (which explains why the context is lost on those other pages).

I'm not sure if we should modify the node handler callback (og_context_handler_node()), or make a new one, so that paths like /group/%entity/%etid/* can grab the context).

What do you think?

amitaibu’s picture

We can extend the node view existing context-handler to work also on group/node/%

Note that 1.x is bug fix only branch...

mstef’s picture

The "node" part of that is an entity-type argument though, right?

Wouldn't it make sense to have a general context handler that can see if *any* page path contains both an entity-type and entity-id, then see if that is a group, then we have our context?

amitaibu’s picture

can see if *any* page path contains both an entity-type and entity-id

How would you do it?

mstef’s picture

Here's something I just wrote to mess with..obviously far from perfect... just thinking

// Get the current menu item
if ($menu_item = menu_get_item()) {
  $entity_type = NULL;
  $entity_id = NULL;
  $entity = NULL;
  $entity_info = entity_get_info();
  // Iterate the map to determine if we have an entity, entity type
  // or entity id
  if (is_array($menu_item['map'])) {
    foreach ($menu_item['map'] as $arg) {
      if (!$entity_type && $arg != 'group' && isset($entity_info[$arg])) {
        $entity_type = $arg;
      }
      if (!$entity_id && is_numeric($arg)) {
        $entity_id = $arg;
      }
      if (!$entity && is_object($arg)) {
        $entity = $arg;
      }
    }
  }
  // See if we have entity data to work with
  if ($entity_type) {
    // Check if we have an entity but no entity_id
    if ($entity && !$entity_id) {
      // Extract the entity id
      list($entity_id) = entity_extract_ids($entity_type, $entity);
    }
    // Check if we have an entity_id now
    if ($entity_id) {
      // Attempt to load the group
      $context = og_get_group($entity_type, $entity_id);
    }
  }
}
amitaibu’s picture

Remember, it should be for 2.x -- you don't have the group entity there anymore..

mstef’s picture

I'm sort of stuck on og1.x right now. I assume the same issue exists for 2.x though?

That bit I wrote obviously needs work, since we can't blindly assume the first number in the URL is the entity_id -- and I guess you could say the same about finding the entity_type...

jayaram’s picture

Did you find a permanent solution ?

jayaram’s picture

Did you find any other solution ?

mstef’s picture

I definitely didn't find anything permanent or wonderful, but I have a workaround in place. It was needed for og_features.

Check out og_features_get_group_context(): http://drupalcode.org/project/og_features.git/blob/refs/heads/7.x-1.x:/o... (warning; it's a little scary)

Aside from this issue, it also is a workaround for #1781218: Calling og_context() in a menu access callback crashes system.

jayaram’s picture

The other solution to this would be to use page manager to create pages or menu tabs. I was able to get the group context on all the tabs this way.

MarcM’s picture

I think i have this same issue with OG 7.2: http://drupal.org/node/1843182

jayaram, I'm quite curious to know how you could get the context everywhere.

jayaram’s picture

@MArcM,

If you creating a new tab on the Group page lets say its " Group Content", Instead of using views, Use page manager and add a new custom page(node/%node/content). make sure your page has the group context(OG group from node) relationship.

rv0’s picture

Anyone found an elegant solution yet?

Currently for Views tabs I'm using custom code in hook_views_pre_view
There I give an og_context.

/**
 * Decides if view is a tab on OG.
 */
function _custom_og_is_views_tab($view) {
  return ( ($view->name == 'announcement' && $view->current_display == 'page_2')
  || ($view->name == 'discussion' && $view->current_display == 'page_1')
  || ($view->name == 'group_content_admin' && $view->current_display == 'page')
  || ($view->name == 'activity' && $view->current_display == 'page_1')
  || ($view->name == 'course_info' && $view->current_display == 'course_info') );
}

/**
 * Implements hook_views_pre_view().
 */
function custom_og_views_pre_view(&$view, &$display_id, &$args) {
  if (_custom_og_is_views_tab($view)) {
    $node = node_load(arg(1));
    og_context('node', $node); // Set og context
  }
}

Works fine, but isn't elegant ;)
A setting on a the view to catch context would be nice, but where in the UI does it belong?

milos.kroulik’s picture

Issue summary: View changes
FileSize
6.86 KB

Unfortunately, solution in #15 doesn't work for me. Is there anything, that should be added to make it work?

I have added following code in custom module:


/**
 * @file views_tabs_set_og_context.module
 * Sets OG Group Context for views, that create tabs on nodes, which are groups or group content. Based on http://bit.ly/1lD5pGO
 */

/**
* Decides if view is a tab on OG.
*/
function _views_tabs_set_og_context_is_views_tab($view) {
  return ( ($view->name == 'prvek_node_tabs' && $view->current_display == 'vlastnosti')
  || ($view->name == 'prvek_node_tabs' && $view->current_display == 'evidence_udalosti')
  || ($view->name == 'prvek_node_tabs' && $view->current_display == 'prilohy_poznamky')
  || ($view->name == 'prvek_node_tabs' && $view->current_display == 'celkovy_prehled')
  );
}
/**
* Implements hook_views_pre_view().
*/
function views_tabs_set_og_context_views_pre_view(&$view, &$display_id, &$args) {
  if (_views_tabs_set_og_context_is_views_tab($view)) {
    $node = node_load(arg(1));
    og_context('node', $node); // Set og context
  }
}

Export of my view is enclosed. The result is, that same view with contextual filter (default value "Current OG Group from context") displays on node but not in tab defined in view.

tanius’s picture

Version: 7.x-1.x-dev » 7.x-2.x-dev
Category: Support request » Bug report

Answering #15:

"A setting on a the view to catch context would be nice, but where in the UI does it belong?

That setting is already there (but does not work, which is why I set this to "bug report"). Namely, for a contextual filter one can already set "When the filter value is NOT available: Provide default value: Current OG group from context". Currently this has no effect.

Also I set it to version 7.x-2.x-dev to bring it up for current development (a fix may be backported to 7.x-1.x).

rv0’s picture

@tanius: that setting is for getting the group from context, not for setting the context

the code in #15 is to set the context

robertom’s picture

Status: Active » Needs review
FileSize
573 bytes

Hi, sorry for my bad english.

I have same problem when I create a views page with path node/%/....

for solve that I have added the patch attached

indigoxela’s picture

Just tested patch #19.

On:
drupal 7.50
organic groups 7.x-2.9

I can confirm that the patch solves the problem.
Block visibility from og context on views pages work correctly again.
No side effects or problems discovered.

Would be nice to get this into the next release.

indigoxela’s picture

Status: Needs review » Reviewed & tested by the community
ajayg’s picture

Since it is RTBC, what needs to happen to get this committed?

  • amitaibu committed 8a55d62 on 7.x-2.x authored by robertom
    Issue #1781386 by robertom, milos.kroulik: Context only set on primary...
amitaibu’s picture

Status: Reviewed & tested by the community » Fixed

Merged, thanks.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.