After a lot of debugging to find out why my context wasn't working I found that with the new ctools hook_ctools_render_alter is not triggered for node pages unless you have a page manager for node pages. Because the hook isn't triggered, the node conditions aren't triggered (see context.core.inc lines 80-94) and thus the condition is never true... .

Not sure how to fix this, but I think this is a pretty major bug (if not critical), because all existing contexts with node conditions will fail, which might lead to some security issues (users viewing content they aren't allowed to etc)

however, since I am using the latest stable versions of both modules, and they both were released in August and I seem to be the first one to notice this, I might of course just be doing something completely wrong... So I will leave the priority of this to normal until someone can confirm this.

If I am doing something wrong, please help me to the right path :-)

PS:
What I did:

created a new context
set a condition of the content type to e.g. article
add a new block as a reaction
go to an article node

I enabled the context inspector and couldn't see the context.
I added a new condition (authenticated user) still didn't see the context.
I removed the node type condition, then I saw the context...

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Jelle_S’s picture

Title: Node related conditions are not met if there is no page manager for node pages » Node related conditions are only triggered for $view_mode == 'full'

Never mind,
It has nothing to do with all that, context also implements a hook_node_view

problem is that there, the conditions are only checked for $view_mode == 'full'. Not sure if that's a bug or not...

tekante’s picture

I'm not sure it is a bug as the node type condition, for example, has this description: "Set this context when viewing a node page or using the add/edit form of one of these content types." which I believe implies the view mode of full when not using page manager. Can you provide more information on your expectations of which view modes would satisfy a node type condition (or specify the other node related condition that you feel may be inaccurate).

klaasvw’s picture

Version: 7.x-3.0-beta4 » 7.x-3.x-dev
Status: Active » Needs review
FileSize
632 bytes

I had the same issue when using display suite extras to allow users to select a different view mode on the node page.

The view mode should not be used to check the node type condition, even if the description mentions "node page". The code is already checking the node object from menu_get_object(), which implies that this is already the node page.

Attached is a patch against head that removes the view mode check. Note that this may break backwards compatibility with implementations relying on the view mode check.

rrrob’s picture

Status: Needs review » Reviewed & tested by the community

#3 works great. Not sure about the backwards compatibility that @klaasvw mentions, but the patch took care of the immediate need of using a view_mode with a context.

idebr’s picture

#3 fixes the use case where the node/[nid] view mode is overridden, for example when an anonymous user visits a paid content page and only sees a small part of the full content.

BBC’s picture

Thanks! The patch in #3 was exactly what I've been looking for. Have been working with context_node and the Display Suite Extra view mode per node feature to allow users to select some different layout options from within a node editing context.

colan’s picture

Issue summary: View changes
Status: Reviewed & tested by the community » Fixed

Committed in d200d51.

Status: Fixed » Closed (fixed)

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

fearlsgroove’s picture

Status: Closed (fixed) » Active

This seems like a heavy handed change .. now a context condition is triggered by a node viewed in teaser mode. That's not what I'd expect this to do .. I think this should get rolled back and separate conditions be created for use cases where nodes are viewed in panels, etc. The inline help text even calls it the "node page" as pointed out in a previous comment.

colan’s picture

@fearlsgroove: Patches are welcome. :)

valderama’s picture

@fearlsgroove Actually this change does not imply that this context condition is triggered by a node viewed in teaser mode, because of the check of the current menu_object. This condition is only triggered if we are on a page where a node is loaded as a menu_object (where %node is in the menu path). I guess that also applies to custom menu items (e.g. my-custom/node-page/%node).

Jelle_S’s picture

@valderama: That's only true if the node id is on the second position (actually first, as it is zero-based) in the path, which is not true for the example you gave (my-custom/node-page/%node). However, it would be true if your path was: my-custom-node-page/%node. See menu_get_object() for more details on that.

fearlsgroove’s picture

Status: Active » Closed (fixed)

Ah I see .. nevermind then :)