I'm currently using Context 6.x-2.0-beta7 together with Panels 6.x-3.0 and I cannot get my head arround it.

Context works fine everywhere except when I choose "Node Pages" as a context setter on overriden content types. I used Panels 3 to override my nodetype gallery put I want to show several blocks which should be delivered from the context module. It seems context is not detecting the content type properly, because of the override action coming from panels.

Is there anything i can do about that? Or is there a workaround? I already lost several days and nights to this issues which tracks me for about 5 month now - yeah, I'm could use another solution or views attach instead of node overrides - but these two modules are just perfect and could be even better if they would work in conjunction.

Maybe its just the way context distinguishes between the nodetypes? any hints pls

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Pasqualle’s picture

context/context.core.inc

function context_nodeapi(&$node, $op, $teaser, $page) {
  if ($op == 'view' && $page && menu_get_object() === $node) {
    // Implementation of context_set_by_condition for node.
    context_set_by_condition('node', $node->type);
...

ctools/plugins/content_type/node.inc

function ctools_node_content_type_render($subtype, $conf, $panel_args) {
...
  $block->content = node_view($node, $conf['teaser'], FALSE, $conf['links']);
}

http://api.drupal.org/api/function/node_view/6
The third param $page is always FALSE in Panels. And it is required for context module to identify it as a node page..

note: This is a quick code analysis only. I did not test if this is what really happens here..

Johnnyk’s picture

Well then I'll take this issue over to the panels issues

Maybe Merlinofchaos has an Idea/Solution or a good reason why this is the way it is ;)

Thank you for you quick answer - I'll link the panels issue as soon as it appears.

Interesting that for example the Custom Breadcrumb Module has no problem to distinguish the node type at all (talking about the 2.x dev release) - But I don't know anything about their approach

mani.atico’s picture

Here is an small module I wrote to prevent this from happening. TEll me how it goes.

mani.atico’s picture

Sent the wrong version, sorry.

Pasqualle’s picture

the 'argument_nid_1' value does not seems like a general identifier of node context in the panels module..

mani.atico’s picture

Hi Pasqualle,

Indeed, this would cause some trouble if the user (or other module) has defined a custom path through ctool's page manager which involves one or more nid arguments (example: examplepath/%nid). I'm not complety sure, but I think 'argument_nid_1' stands for 'argument_{type}_{delta}'. So I agree with you: maybe checking 'argument_nid_1' is not the best way to do it, 'gramatically' speaking.

Anyway, the real problem is determing if a 'node page' or a costum path is being rendered. This information is available in the $task argument passed by the alter function. Here is what dprint_r prints:

Array
(
    [task type] => page
    [title] => Node template
    [admin title] => Node template
    [admin description] => When enabled, this overrides the default Drupal behavior for displaying nodes at <em>node/%node</em>. If you add variants, you may use selection criteria such as node type or language or user access to provide different views of nodes. If no variant is selected, the default Drupal node view will be used. This page only affects nodes viewed as pages, it will not affect nodes viewed in lists or at other locations. Also please note that if you are using pathauto, aliases may make a node to be somewhere else, but as far as Drupal is concerned, they are still at node/%node.
    [admin path] => node/%node
    [hook menu] => page_manager_node_view_menu
    [hook menu alter] => page_manager_node_view_menu_alter
    [handler type] => context
    [get arguments] => page_manager_node_view_get_arguments
    [get context placeholders] => page_manager_node_view_get_contexts
    [disabled] => 
    [enable callback] => page_manager_node_view_enable
    [module] => page_manager
    [name] => node_view
    [path] => sites/all/modules/ctools/page_manager/plugins/tasks
    [file] => node_view.inc
    [plugin module] => page_manager
    [plugin type] => tasks
)

I really don't know which value should be used to determine if a 'node page' is being rendered, but maybe 'admin path' or 'title' are fine.

I attach the new version of the module.

Johnnyk’s picture

That is absolutely awesome!

Thank you very much!

pokadan’s picture

Does not work for me. I use Context 6.x-2.0-beta7 together with CTOOLS 6.x-1.2.
As I understand it, this is not a Panels incompatibility but rather a Ctools incompatibility.

Enabling the module at http://drupal.org/node/595744#comment-2136758 does not change anything for me.

yhahn’s picture

FYI, I committed a very similar implementation of this to the 3.x branch: http://drupal.org/cvs?commit=326196

mstef’s picture

I'm still having this problem with:

Context 6.x-2.0-beta7
Panels 6.x-3.3
CTools 6.x-1.3

Where do we stand?

mstef’s picture

#6 works perfectly.

So this is a context problem? Is it being committed?

Anyway to turn that into a patch, rather than another module?

Steven Jones’s picture

Title: Context not set on Node » Node page views when using Panels don't trigger Context reaction
Assigned: Unassigned » Steven Jones
Status: Active » Needs work

The code from #9 should be easy enough to integrate into Context 2.x.

Steven Jones’s picture

Category: bug » feature
Issue tags: +context-2.x-rc-blocker

Yup, need to backport this.

Steven Jones’s picture

Status: Needs work » Fixed

Status: Fixed » Closed (fixed)

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

james.williams’s picture

I'm re-opening this, because unfortunately the structure of the CTools contexts array that gets inspected has changed, so this issue is once again a problem. The attached patch fixes this.

james.williams’s picture

Version: 6.x-2.0-beta7 » 7.x-3.0-beta1
Status: Closed (fixed) » Needs review

And now actually changing the status of the issue...

febbraro’s picture

Status: Needs review » Closed (fixed)