I started digging into context and so far I have been really liking the change in work flow. Our site designs always end up being very block oriented, with various blocks displaying or hiding based on "context" (in the old days a path pattern). I like the work flow of leaving the blocks admin page nearly empty and setting up contexts to handle visibility.

The current site I am working on uses Organic Groups and I am using many group related blocks in a few different contexts. The OG module provides a good number of context related helper functions that I would love to put to use.

I would like to get a little more familiar with the context module before I try anything too crazy but I am planning on working on a patch that will add a PHP evaluation condition.

I'd love to get some feedback and just figure out if this has been tried before, or even solved and I just didn't find it.

CommentFileSizeAuthor
#16 og_context.patch1.47 KBsteven jones
#15 og_context.zip1.03 KBmstef
#2 context_php_code_condition.patch1.23 KBte-brian

Comments

pasqualle’s picture

pasqualle
Location 🇭🇺 Budapest
commented

I think, this was a similar feature request #305112: Integration with Conditions module

te-brian’s picture

te-brian commented
Status: Active » Needs review
StatusFileSize
new context_php_code_condition.patch1.23 KB

Here is a quick SVN patch I made that seems to be working. I'm sure there could be more security and would be excited to see any suggestions for improvements.

I must say that I was expecting to write lines and lines of code, but the context UI, set/get, and caching are very well abstracted. One of these days I may even play with some OG support.

te-brian’s picture

te-brian commented

Quick Bug Question:

The above patch seemed to work fine for the first couple php conditions I set, but then I ran into one that would not apply. Var_dumps showed that the context_set was running. As a workaround I added a call to context_active_contexts(TRUE) to reset the static array. Any idea what could be going on? Is the context_page_alter hook too late in some special cases?

yhahn’s picture

yhahn commented

I think your guess about a late condition check is a good one -- if you have the actual code you are using it would tell more.

I'm glad you found it easy to write a PHP eval condition... to be honest I am not very fond of PHP evaluation features in Drupal modules. Another point of perspective to consider is that I would slowly like to move toward context exportables (and any other exportables) not having *any* evaluatable PHP code for a variety of reason (one of them being that exportables could be stored securely in a non-PHP code format and managed/loaded from, say, the files directory).

To make a long story short:

  • I'm not crazy about committing the patch but I think you should continue to use it to address your needs. You're also welcome to put it in a separate module (just implement the hooks there). If you have a very good argument for PHP eval conditions I am open to them.
  • It sounds like for your use case you might as well write OG-context based conditions... what do you think?
te-brian’s picture

te-brian commented

I agree, php conditions will always be used solely because the specific condition you need does not exists. In 9/10 cases a reusable condition could be written to solve your needs and the needs of future users. In my case, the addition of the php condition was to allow me to use og_get_group_context() and other helper functions to control context. A full OG context module would be the more elegant solution and be much more reusable.

As to my current problem, below is my context_page_alter hook. I've seen it used to set context in the conditions available in the stable release, so I'm not quite sure why it fails sometimes in my case. Like I said, clearing the active contexts after my check seems to work but undoubtedly has performance ramifications. I'd love your thoughts on how I can get it to register reliably or how to better test why it doesn't register in some cases.

/**
 * Implementation of hook_context_page_alter()
 */
function context_contrib_context_page_alter() {
  foreach (context_enabled_contexts() as $identifier => $context) {
    // context by php_code
    if (!empty($context->php_code) && is_array($context->php_code)) {
      $php_code_return = drupal_eval($context->php_code[0]);
      if ($php_code_return) {
        context_set($context->namespace, $context->attribute, $context->value);
      }
    }
  }
  context_active_contexts(TRUE);
}

I need the php code to evaluate as late in the page's life cycle as possible so that other modules (notably OG) have had a chance to do their magic before I call their functionality. For this reason the init() hook is certainly not an option.

Thanks,Brian

yhahn’s picture

yhahn commented
Title: PHP Code Condition » Set context by OG context
Assigned: Unassigned » yhahn
Status: Needs review » Active

I'm changing the title/status of this case.

I'm not quite sure why the page_alter() is not running reliably so I'll have to look into it a bit more. Specifically, I take it you are trying to set the context on the basis of the group whose og_context has been set?

te-brian’s picture

te-brian commented

Hey.. sorry for abandoning this issue for so long. So far, we have not run into this same issue. Or rather, the small fix seems to be working. Once we actually get down and dirty with optimization we'll see if this causes any alarm. Also, we're still undergoing a lot of general page load modifications (memcache, page caching, centralized authentication, eventually authcache, etc.). Lots of variables to work out.

As an aside, at the time I had posted this issue initially the Context module was nothing more than a block visibility utility to me. Boy was I wrong!

After taking some time (and borrowing some insight from a co-worker) I now see context for what it truly is: a generic way to set and get global variables based on common Drupal "attributes". When approaching it from this standpoint (for example section = blog, or page = registration, or template = fancy), you can really get a lot out of it. We are now using context for much more than block visibility and I sure have tons of room to get even more utility out of it.

In the very least we have been able to consolidate contexts much better and reduce the redundancy of similar block and theme settings.

amitaibu’s picture

amitaibu
Primary language Hebrew
Location Israel
commented

@yahn,
> (one of them being that exportables could be stored securely in a non-PHP code format and managed/loaded from, say, the files directory

I'm not sure I'm getting the above. When I think about Views and Rules, they allow me to export their code which might have PHP as-well.
I think that having the "Execute PHP" condition just gives a powerful way of using my own logic on the context.

jide’s picture

jide commented

See #689972: Context module support for 3.x branch.

steven jones’s picture

steven jones commented
Version: 6.x-2.0-beta2 » 6.x-2.0-beta7
Assigned: yhahn » Unassigned

Yeah PHP evaluation is not going to get into context 'core' any time soon (ever, really).

I'd be open to someone backporting #689972: Context module support, well just the OG bit, if they wanted.

mstef’s picture

mstef commented

What's the status here?

steven jones’s picture

steven jones commented
Status: Active » Postponed (maintainer needs more info)

@mikestefff See comment #10.

marcp’s picture

marcp commented

The OG portion of the latest patch in #689972: Context module support is working the way I would expect it to. It sets context based on the "group context of the node being viewed."

I think just the OG portion of that patch should be pulled out so we can push it through without the Domain Access portion.

@Steven Jones - should I roll a patch with just the OG portion? The functionality can be tested out over in #689972: Context module support before you answer if you want.

steven jones’s picture

steven jones commented

Yeah, I think this functionality should get into the 3.x series before the 2.x series.

mstef’s picture

mstef commented
Status: Postponed (maintainer needs more info) » Needs review
StatusFileSize
new og_context.zip1.03 KB

Contrib module for OG support in 2.x.

Works fine for me. Might not be the best way to implement it. It was done fast. Check it out and let me know. This is the only way I could think of to accomplish this.

Requests are made in hook_init() to check for group context. Because some views are in group context, but that can't be determined in hook_init(), a request is also made in hook_views_post_render().

steven jones’s picture

steven jones commented
StatusFileSize
new og_context.patch1.47 KB

Here's the zip from #15 as a patch so I can review it.

mstef’s picture

mstef commented

Sorry about that. Since it's a separate module, I didn't think a patch was called for. I can integrate it with context_contrib then make that a patch? I think it would be best if it was a part of that module. No?

steven jones’s picture

steven jones commented
Status: Needs review » Needs work

Here's quite a thorough review:

+++ og_context/og_context.info	2010-05-04 12:48:50.000000000 +0100
@@ -0,0 +1,5 @@
+name = OG Context

This module should probably be called 'Context OG'.

+++ og_context/og_context.info	2010-05-04 12:48:50.000000000 +0100
@@ -0,0 +1,5 @@
+dependencies[] = context

It should also depend on OG.

+++ og_context/og_context.module	2010-05-04 12:46:32.000000000 +0100
@@ -0,0 +1,37 @@
+  if (module_exists('og')) {

Don't need this if statement if you add og as a module dependency.

+++ og_context/og_context.module	2010-05-04 12:46:32.000000000 +0100
@@ -0,0 +1,37 @@
+    $items['og'] = array(
+      '#title' => t('Organic Groups'),
+      '#description' => t('Set this context when in a group context.'),
+      '#options' => array('1' => t('True'), '0' => t('False')),
+      '#type' => 'radios',
+    );

This condition just seems a bit bizarre, I was expecting some code that would allow a user to specify different contexts to fire based on groups or group types being viewed, not a really coarse and not hugely useful 'global' group context set condition.

+++ og_context/og_context.module	2010-05-04 12:46:32.000000000 +0100
@@ -0,0 +1,37 @@
+// Detect group context after a view is built

This should be standard doxygen, not an inline comment.

+++ og_context/og_context.module	2010-05-04 12:46:32.000000000 +0100
@@ -0,0 +1,37 @@
+function og_context_views_post_render($view, $args) {

It's probably better to use the hook_context_page_condition() hook to look for the og context, it occurs just before the context reactions happen.

+++ og_context/og_context.module	2010-05-04 12:46:32.000000000 +0100
@@ -0,0 +1,37 @@
+// Detect group context on init page view

As comment on comment above.

+++ og_context/og_context.module	2010-05-04 12:46:32.000000000 +0100
@@ -0,0 +1,37 @@
+// Set group context in context if available

As comment on comment above.

+++ og_context/og_context.module	2010-05-04 12:46:32.000000000 +0100
@@ -0,0 +1,37 @@
+  context_set_by_condition('og', $group ? TRUE : FALSE); ¶

We don't tend to assert the negative in Context, so if there's no OG context to set, don't set it.

Apologies for the lame documentation in Context 2.x, feel free to file patches to add some more!
You can add advanced help to context conditions and reactions now, have a look at the examples in context.core.inc and the help itself in context_ui/help.

Powered by Dreditor.

mstef’s picture

mstef commented

Awesome review. Like I said, this was whipped up in like 20 minutes just trying to get functionality before making it 'nice'. I was also hoping it would make it's way into context_contrib, so I didn't spend time with naming or comments.

I'll make all of the changes now and post back.

Possible to put this into context_contrib or should I just bank of it being a custom module for me?

mstef’s picture

mstef commented

As for the 'global' context options, etc, this is how all of the group-related blocks are triggered. They are all dynamic, so they automatically adjust content to the group context. If you wanted to show only on a group type node, you can use the node context which is already in there.

mstef’s picture

mstef commented

We don't tend to assert the negative in Context, so if there's no OG context to set, don't set it.

What if you want the context set to 'no group context' - otherwise, show on FALSE?

mstef’s picture

mstef commented

hook_context_page_condition() does NOT work when viewing a group homepage - though, it does cover the views pages which have a group argument. I'd still recommend the way I had it first because of this.

Disagree?

steven jones’s picture

steven jones commented

I think I would be happier if this was a standalone bridge module, context_og or og_context or something. Rather than in the Context package. You could then do 2.x and 3.x integration in one fell swoop, as per http://drupal.org/project/context_http_headers.

I'd be happy to have some level of involvement in that project if you want, have you set one up before? Do you want me to review some code?

steven jones’s picture

steven jones commented

What if you want the context set to 'no group context' - otherwise, show on FALSE?

Use the 'default' context condition.

steven jones’s picture

steven jones commented

hook_context_page_condition() does NOT work when viewing a group homepage - though, it does cover the views pages which have a group argument. I'd still recommend the way I had it first because of this.

Disagree?

Probably doesn't hurt too much to try to set the context multiple times, factor out your code that does the setting and call it from as many places as you can think of (if you want).

mstef’s picture

mstef commented

Use the 'default' context condition.

Could you explain that, please?

I understand not including it - that makes sense actually. I'll polish this up and consider adding it as a project.

steven jones’s picture

steven jones commented

In the latest dev of context 2.x there's a 'default' condition, if no context is set within a namespace/attribute already, then the default context will be activated.

marcp’s picture

marcp commented

Regarding hook_context_page_condition() to set the OG Context -- that's working fine so far in the 3.x version that's attached to comment 13 in #689972: Context module support.

@mikestefff - if you don't already have CVS access it would be good to get your application in so you can maintain this awesome module.

mstef’s picture

mstef commented

Is it handled different in Context 3.x because I haven't gotten it to trigger on group home pages. It's overridden by a panel but that shouldn't matter.

marcp’s picture

marcp commented

I don't know -- I haven't looked at the 2.x code yet but will do so as soon as I get a "Set OG Context" reaction into the 3.x branch. What version of OG are you using?

It sounds like Steven's wanting to see this as a separate contrib module -- I think that makes sense. In D6 I think we're going to hit a lot of weird cases because OG sometimes need to have that context set early and sometimes it's not even possible to set it (like with Views arguments).

mstef’s picture

mstef commented

I'm using the latest OG.

This works now for my case, so I don't mind it being pushed into anything. I'll get in hosted on here soon, hopefully.

I still can't get the 'false' case to work, but I don't need it right now, so I scrapped it. (sort of in a rush with things)

steven jones’s picture

steven jones commented
Status: Needs work » Closed (duplicate)

The path to OG integration is now described in #790214: OG Integration - Meta Issue.