Context module support

FYI, patch seems to break beta4 release. Working to debug currently. Will post if I find a fix.

Okay, in the patch for context.module, I think that swapping out:

function context_init() {
 
   ...

   $plugin = context_get_plugin('condition', 'domain');
   $plugin->execute();

   ...

for:

function context_init() {
  ...

  if (!empty($map['domain']) && $plugin = context_get_plugin('condition', 'domain')) {
    $plugin->execute();

  ...

does the trick. "Require all conditions" isn't working for me when trying to set the "domain" and "path" triggers, but I'm not sure that has anything to do with this patch.

What's the status of this?

We're interested in this for OG - is there a reason that Domain and OG are covered in the same patch?

Would this have a better chance of getting in if the OG and Domain functionality was split into separate patches?

And in looking at the code, it looks like the context is set by looking at the group type.

We'd also be interested in having context set by a nodes group affiliation; so, for example, a node in group A could trigger one context, and a node in group B could trigger a separate context.

Agreed that this would be better split into two patches. I'll take a look at that soon if nobody else gets to it.

Attached is a single patch file that includes all 3 files from the initial issue along with the fix in comment 3. It applies cleanly to DRUPAL-6--3 but I haven't yet tested the functionality.

Apply the patch with:

  patch -p0 < context-domain-og-conditions.patch

If this issue was waiting for a proper patch, then it's here now. We may still want to address this with separate patches, but this is at least a starting point for the community to test a clean patch.

I've tested the OG functionality in the patch and it appears to be working as designed. I haven't looked at the Domain Access portion, and probably won't ever get around to that. I think we should split these two pieces of functionality out.

Would like to get more eyes on the OG portion.

Are we supposed to include the original 3 files in the context dir, then apply the patch, cause the patch doesn't apply by itself?

oooooh this is for 3.x

Sorry..

How is that - stable?

@mikestefff - we've been evaluating 3.x and it looks pretty good. This OG stuff is critical for us.

The patch in #8 should apply cleanly if you run it with the command above -- no need to get any other files.

I actually don't like this approach of building the OG/Context interaction directly into the Context module, so tomorrow I'll be posting a different implementation as a standalone module. The standalone module implements hook_context_page_condition() which seems like a better place for this. It allows us to also make sure context gets set properly when looking at Views that have group nodes as arguments.

I should have learned about hook_context_page_condition() by reading over the Context code, but instead I learned about it here.

If any of the Context maintainers are paying attention, I'd love to get clarity on whether you feel contrib module context-related code belongs in Context or in separate modules. I'm only looking at the 3.x branch of Context, but it seems like it would clean up the code to get that stuff out of the core codebase.

Very interesting - sounds like you're on the right path. Unfortunately, I'll have to wait until v3 is out of beta. I guess for now it's blocks with PHP snippets. I hate that...

Here is a functional contrib module called ogcontxt -- it provides 2 condition plugins:

OG - group type context

Set this context when viewing a node or other page that is in any group of the selected types. This is a modified version of the original "Organic Groups" condition from this issue.

OG - group node context

Set this context when viewing a node or other page that is in any of the selected groups.

Both of these conditions fire on any page where the OG context is set -- not just on nodes. So, they will work on views that take group nids as arguments, and they will also work on og_vocab pages where og_vocab sets the group context. If you only want your context to be set on actual node (or node/edit) pages, you can combine these conditions with other conditions to get things working.

The conditions fire in hook_context_page_condition(). The problem with "Require all conditions" from #3 is fixed also -- instead of calling context_set() in the execute() functions, this version calls condition_met() which appears to be the right way to go.

After installing, it may be necessary to go to admin/settings/performance and clear the cache in order to see the new conditions while building contexts. If you were using the previous patch, you'd be better off removing it and running this separate contrib module.

Questions I've got:

1. Does this belong in OG?
2. Does this belong in Context?
3. Is this best provided as a separate contrib module?

I'll be testing this out later tonight/over the weekend.

I tested out the module from #13. It works great. The only potential issue I ran into is when I first enabled it I got wsod on context edit pages, which was only resolved after a clear cache.

I think context mantainer (yhahn?), and OG mantainer (Amitaibu I believe) should both have a chance to look at this and decide if they want to incorporate it, otherwise I think it makes alot of sense as a contrib module, much like og_panels. I posted an issue in OG for them to consider this: #774768: Consider og/context integration module and decide where it belongs

I would mark this as needs work, but I think this is already enough of a thread high-jacking so I will leave it be.

Sounds like we need to clear the context cache during installation.

I am working on adding an option for "set context on node forms" like the option that exists for the node type condition.

The only way I know to test whether the current page is a node form however is to see if arg(1) == add or arg(2) == edit, but this seems messy and fragile. If anyone knows of a cleaner way to test for this please let me know.

@entrigan You'll probably want to use a hook_form_alter to look for the node form and set the context in there.

Hi everybody,

I'm here from http://drupal.org/node/742676 , I've just tried #13 module but it doesn't resolve my issue.

Is it possibile to have an integration with OGUR module? That's why my users has ONLY OGUR "runtime" roles (not core roles) and seems that there is no way to keep Organic Groups context OUTSIDE Organic Groups pages, such as Views pages for example. That's why OGUR roles works only under an Organic Group context, and outside it my users lose their roles!!! The consequences are the following:

• Views access restrictions by user roles doesn't work because Views checks the CORE role of a user, and my users doesn't have CORE roles, but only "OGUR roles" that works ONLY under OG context.
• Rules module has the same problem like Views: it cannot chek OGUR roles ouside OG context and I cannot setup rules conditions properly.
• Views Bulk Operations roles restrictions: the same. It cannot check runtime OGUR roles but only CORE roles

The issue is described better here: http://drupal.org/node/742676#comment-2855062
Also I wrote a STEP by STEP to recreate my scenario here: http://drupal.org/node/737292#comment-2846284

I'm around this problem since months and my entire project is stopped due to this issue. I'm very desperate! OGUR maintainer seems not to give enough importance to this request (see http://drupal.org/node/737292 ).

What can I do? Please help me!

Thank you very much

MXT

@marcp:

I'm assuming this is for 6.x-3.0. Is it possible to make this work for 6.x-2.x also?

@entrigan - I think the way to go with the "set context on node forms" is to build your contexts with multiple conditions. The conditions provided by this module are as generic as possible to meet the most common use case that we have come across - displaying blocks for an OG. The conditions provided here work whether you're looking at a node, node/edit form, view that takes group as argument, og_vocab term page, and any other OG add-on that sets OG group context properly.

You can combine this condition with, for instance, the "Node type" condition to achieve what you are trying to do. Make sure you check the "Require all conditions" checkbox so you get AND behavior (ie. Node types of page, and story, except for on node forms, AND OG group type context).

@mikestefff - this is for the 3.x branch of Context. I haven't yet looked at the 2.x API to see how it has changed. Have you tried it on 2.x yet? If not, please do so and let us know what happens.

@MXT - it sounds like there are other issues with OGUR. If this module gets released as a separate contrib module, you should feel free to open an issue there.

@Steven Jones - should I release this as a separate contrib module?

@marcp, the require multiple conditions does not work because that would only set the context on node:type pages, not on other pages that have their og context set, e.g. views. The way I see it the setting could best be achieved in two possible ways:

1. follow steven jones's suggestion and use hook_form_alter. I am not 100% sure this will work because of the timing, but I am assuming it would because steven suggested it.

2. change the existing conditions to be more granular: e.g. add negation options (to all conditions), and have two options for the node:type condition: a) Set on node pages b) Set on node forms

I like 2 best, so perhaps I should create a feature request.

@entrigan - I like your option 2 best also -- this will allow us to keep the execute() calls centralized in just one place, where I think they belong, hook_context_page_condition(). I'll be adding this in today and will post a 6.x-0.4 release here unless I hear otherwise from the maintainers that they think this belongs in a separate contrib module.

1) Is #13 a stand alone module, or shall it be used with Context?

2) Many people, including myself struggle to get Views working in OG
http://drupal.org/node/774478
http://drupal.org/node/404978
The context is lost when the View is called from outside a specific group node (e.g. a menu itrem).
Would this module help?

@jvieille - #13 depends upon Context. It adds two new condition plugins. Please give the module a try. I will be updating it again "soon" (but I said that a few days ago too).

I have seen your other issues in the OG queue. Keep plugging away. OG is great, but it's not perfect. The best thing you can do there is give folks exact steps to reproduce your issues.

Marcp, I think that there's need to add a "provide OG context" to the REACTIONS LIST.

That's why I actually can choose a CONDITION in the conditions list (e.g "views" or "path" or "sitewide context") that doesn't have a OG context.

For example, I want that a particular path e.g. "/group/workflow" that BE put under an OG Context, derived from user's OG who is navigating the URL.

So if USER 1, belonging to GROUP 1, is viewing "/group/workflow" URL, the system reaction is that to provide GROUP 1 context (and finally "RULES", "VIEWS access restriction" an so on may check OGUR roles correctly.... I HOPE!)

What do you think about that?

Anyone willing to whip up OG support for 2.x?

Since I still have no clue to get OG context in simple situation (calling a View from a standard menu item), I am blowing on embers

Oooh but so simple..

return og_get_group_context();

Returns group object if context or FALSE.

Where can I find some doc for the v2 API? I'll do the OG support for it...seems easy enough.

EDIT: oooh maybe look in the module first..

@mikestefff: http://drupalcode.org/viewvc/drupal/contributions/modules/context/README...

I'm not sure I want in Context 2.x btw, convince me.

@Steven Jones:

Thanks, I found that doc in the module. It's lacking quite a bit, as it doesn't explain how to set the context, but I've figured that out after looking at the context_contrib module.

Why 2.x? Well it's still only available as an RC. How long before it even becomes a full release? With that in mind, how long before 3.x even comes out of dev? This is for a very high-profile distro and I need something stable, now.

Ok..that took 30 minutes. 2.x support for OG in a contrib module.

http://drupal.org/node/493668#comment-2926468

@MXT - This new release of ogcontxt has a new "OG - set group context" reaction. It gets fired on hook_init() so it should work nicely with the conditions provided by the module. The one scenario I tested with this is to use the reaction to set group context based on a path.

nice marcp, I think you should release this as a contrib module.

OG integration is now covered over in #790214: OG Integration - Meta Issue.

This issue is now only about Domain integration, which I would suggest should be handled in a similar way to OG integration in any case.

Marcp: thank you very much for your work!

Yes, it works great: OG Context is seated up correctly based on path or on a View.

But unfortunately it doesn't resolve my problem, for 2 reasons:

1. In the "OG - set group context" reaction I can choose the group I have to get the context from a drop down, but at this point I can't know the group a user belongs to... I'd need another option similar to "Set group context based on Group which acting user belongs to". (It would be enough for my case, where a user can belong to only and only one group, but in other cases, where a user can belong to many groups, this option would retrieve THE FIRST or main Group a users belong to, I think)
2. Much to my chagrin, OGUR roles access restriction to Views still aren't working. I think at this point it's a "OGUR integration with Views" issue, and I've already opened an issue in the OGUR issues list ( http://drupal.org/node/737292 ) since a month, but OGUR maintainer doesn't seems to have time to resolve it

I don't know what i have to do now....

Thank you

MXT

Hi all, there was a number of problems with the proposed patch in regards to the Domain Access integration so I wrote a Domain Context module to integrate the Domain Access module and Context module. The company I work for is requiring me to upload it through their own CVS account (which doesn't exist yet), so as soon as their CVS account application is approved and the project page is on d.o I'll notify everyone here.

Thank you very much rjstatic, I can't wait for it!

MXT

We're still waiting for approval from a repository maintainer on the Domain Context module . matt2000 suggests we get testers to confirm that the code works. It would be great if someone would checkout the code and confirm it works on the following thread http://drupal.org/node/810088
Thanks!

Providing an updated version of the context domain patch.
Using in staging, reviewed by 2 developers.

Should one release this as a separate contrib? (Will context natively only support core-like modules?)

Tracking.

Yes, I think it will be best if this lives in its own project or is added to the Domain Access project itself. I will leave this ticket open -- please close once this code finds a home.

Passing this to domain.module
Will you integrate this functionality into current -dev?

I would prefer this be released as a stand-alone project. While the patch itself is pretty trivial, supporting it may not be. I am not prepared to support Context.

Also replied to the CVS application and marked it RTBC.

Tracking. Can't wait to test the new module...

Tracking. Domain-Context integration sounds very useful, I will probably use it...

According to #810088: rasantiago [rasantiago] the stand-alone module has been approved but I can't find it anywhere yet?

I've sent a message to rasantiago using his/her contact form:

Hi rasantiago,

Just letting you know, in case you haven't seen; your CVS application on d.o was approved:
http://drupal.org/node/810088

If you don't get a chance to within the next few days, I'm going to open a project for your module as posted in that issue. I'll gladly transfer maintainership to you if/when you're available again.

Cheers,
xjm

I'll open the project within the next week if we don't hear back.

Please do so,
I already tried to contact him using the contact form a few days ago without success.

I have created this project and added it to CVS. A development snapshot will be available within the next 24 hours for testing. I will transfer maintainership if/when rasantiago is available.
http://drupal.org/project/domaincontext

Marking "won't fix" for inclusion in either parent module. Please open any issues in the queue of the new module.