I am working on site that uses Panels Everywhere and some panes need a group context. For this site, we have a group node type. Other node types like news and events can be placed in a group. So for some pages the group context is the current node. For other pages it needs to be a relationship.

So in this case, a CTools context that was little more than a wrapper around og_context(node) would do the trick. However, it seems that the plugin has to be relationship plugin because the returned context is a node and CTools is already providing a node context. So here is a patch that provides a relationship plugin. The incoming context for the relationship is optional and I have a "fallback to og_context()" option.

I'd like feedback if this is the right approach for this use case. And if so, the UI labels and titles could use some better text.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

amitaibu’s picture

Status: Active » Needs review

Correct status

amitaibu’s picture

Before the review, I didn't understand why you can't call og_context() (for the relationship plugin) -- as it return the group_type and group ID -- everything you need to pass on to CTools?

stevector’s picture

The patch uses og_context() as fallback but not the primary means of deriving the context because relationship plugins require or strongly suggest basing the returned context off of an incoming context. og_context() does not take an incoming context argument. It uses handlers defined in hook_og_context_negotiation_info().

So using og_context() inside of a relationship plugin is not a perfect fit because the returned context is not really based on the incoming context. Perhaps this plugin should just set it's incoming context to new ctools_context_optional(t('Not Used'), 'any'); and the UI form element for picking an incoming context would be form altered out because og_context() is just going to use it's handlers to pull a context out of the menu_get_object().

amitaibu’s picture

> new ctools_context_optional(t('Not Used'), 'any')

I think I prefer this approach

stevector’s picture

Here's the simplified approach. The CTools UI throws PHP warnings if there is not actually an incoming context set. So in this patch I've required an incoming string context and added a description that it will not actually be used.

amitaibu’s picture

FileSize
46 KB

I was looking more in depth and went back to the comment

So for some pages the group context is the current node. For other pages it needs to be a relationship.

Sorry, I'm actually not sure why it's not a regular context (i.e. not relationship) -- can you please (re)explain ? :)

stevector’s picture

Status: Needs review » Needs work

It's not a regular context plugin because there are already regular context plugins for nodes and every other entity type. My understanding of context plugins is that it's one-per-type-of-data. I may be wrong about that.

So I thought my only option for og_context() was a relationship plugin where the incoming context really doesn't matter. I've since found another option for getting the results of og_context() into Panels Everywhere: #1784034: Panels Everywhere Integration

For this issue, I think there is still a use case for the "get me the organic group node that this other article node is in, or return the current node if it is a group" relationship plugin. It's not what I need currently for my client but I imagine it'll come up again. That plugin would be the original patch without the og_context(). It's basically just _group_context_handler_entity() wrapped into a relationship plugin.

Leaving as "needs work."

amitaibu’s picture

get me the organic group node that this other article node is in, or return the current node if it is a group

In that case it will indeed be a relationship plugin, but not depending on og_context. It can be something along:


if (og_is_group('node', $node)) {
  // The node is also the group.
}
elseif ($gids = og_get_entity_groups('node', $node)) {
  // $gid['node'] holds the group IDs.
}
hefox’s picture

I don't believe a relationship is needed here? Can get the group information via "Node from node(On node: label (field_name)"

stevector’s picture

Yes, you can if you know that the incoming node is not the group. The relationship plugin discussed here would be needed if the incoming node/entity might itself be the group.

malberts’s picture

FileSize
2.27 KB

Here's a trick for if you need to get the current group in Panels.
1. Make a view with a "Context" display that uses the og_context default contextual filter, "Current OG group from context", to get the current (node) group. See attached export.
2. In Panels add that view ("View: Current Group") as a context and then you add a Relationship "Node from view" with row = 1.

I know this is not a solution to this issue (proper CTools integration) and you'll be incurring a performance penalty (don't know if it's much) for invoking Views for this, but it might be an adequate workaround until something happens here.

Iztok’s picture

How can you add a Views as a context in Panels?

I am still confused that ist not posible to get Group on a Node page - am I missing something?

heyyo’s picture

I would like to use the OG context on node edit/add page.
All my "node add" links are using Entity Reference Prepopulate in URL so OG context is able to retrieve this OG Context, but this context is not accessible from node edit Panels page, or didn't find how to retrieve it ?
And in the same node edit/add panels page, I don't see access to path arguments like any other panels.
I will try malberts solution provided #11

milos.kroulik’s picture

Issue summary: View changes

I confirm, that approach from #11 seems to be working.

milos.kroulik’s picture

japerry’s picture

Issue tags: +affects drupal.org

we're using the patch in #5 to manage some of our panels on events.drupal.org and will probably need something similar for drupal.org as we roll out the content strategy.

I don't like the random string context. It'd be great, for usability sake, to have a context with empty data that says og context. but thats more of a syntax thing, it'd do the same thing either way.

japerry’s picture

While Patch #5 still applies with patches, it doesn't git apply because of the fuzz. here is a re-roll of #5.

Anonymous’s picture

#11 is still working solution. Thanks!