Integration with View modes (core functionality)

I feel this is out of the stated scope of this project.

Furthermore, it's very feasible that sites would want this functionality but not define custom view modes.

I'm a little puzzled why this module would need add such a feature though. View modes are supported by Drupal core natively and we should have the necessary APIs to list view modes without needing this module. Why can't this support just go into the Context module since it's a Drupal core feature?

I really interest by this fonctionnality. For my case as exemple, I display houses in two differents ways, one for standard houses and the other for luxe houses. Both uses the same content type, only the display mode change. As the successor of build mode which include this fonctionnality this would be great to also have this one.

Thanks

Again, view modes are baked into Drupal core, and use of them does not require this module at all. This is why I still insist that it is in the Context module's best interest to add the integration there. Just because Build modes supported this in D6 doesn't mean that we should for D7. Moving to the Context issue queue.

Attached patch is based on #2, for Context.module.

Note that hook_entity_view_mode_alter() is fired before hook_node_view(). The latter is the hook used to trigger all node-centric contexts, meaning a context that is dependent on node state will not be set at the time this hook fires. To get around it for my project I created a custom context condition that evaluates the loaded node object, which is sufficient for my purposes.

Extending from #11, and the comments in the API documentation, node conditions are triggered only on "full" view mode. If you have an alternate view mode, you need to manually trigger the node conditions:

/**
 * Implementation of hook_node_view().
 */
function example_node_view($node, $view_mode) {
  if ($view_mode === 'new_view_mode') {
    $object = menu_get_object();
    if (isset($object->nid) && $object->nid === $node->nid) {
      context_node_condition($node, 'view');
    }
  }
}

This is a sufficiently significant break with Context module expectations, that I think it needs a solution before this functionality is at all worthwhile.

Quick Solution

This reaction has a checkbox that indicates whatever View mode it sets should be treated as equivalent to full for purposes of context module condition evaluation.

Deep Solution

The View Modes system should have an ability to acknowledge modes other than full/default as "full page views", this configuration setting would be checked as opposed to simple the machine name of the mode.

#10 doesn't work for me - Latest context version (7.x-3.2).
I'm using Path condition.

Hi you all.

I also think that having this natively on Context is a great idea, since we can define new views modes, but I've always wonder how to change them dinamically. The only place I know is on Views, but I always prefer use fields on Views. My impression is that being able to set different contexts for showing the same node with different view modes depending on different conditions, is the real sense on having view modes. Or told otherwise, context is logically the right way to use view modes.

For example, I can use on context a condition to detect mobile platforms and then display them with a proper view mode, meanwhile the node is displayed with a full fields display on a context for desktop screens. This is a feature I've been looking for a long time and with that reaction on Context would be a great site building technique.

In fact I also think that responding to tablets and phones, or if you prefer having a "condition" based on "breakpoints" might be core on Context, at least nowadays ;-)

Just my 2 cents. Thanks.

All in all, I'll try to have a test on Plach patch. Thanks!

Hi you all,

I see that this thread is old and not very active but I'm very interested on it. I've implemented Plach strategy on #2 but instead of patching Context I've converted it on a new module that extends Context. You can see the module attached. It installs as any other module and appears inside any context set available on the reactions list.

It's not working, as pointed on comment #13, but after many hours of studying hooks related on node view I have to admit that I don't know why and how to solve it. It would be great if someone could help, since considering that maybe it's not a good idea to extend core Context with that feature as Dave Reid defends, on the other hand for me it's clear that Context itself is a very good environment to change node view display depending on different reasons (maybe Rules could be another place but for me Context it's a core element of every Drupal project I work with).

So, if anyone is interested on having a look at the module any help would be very appreaciatted.

Hi JordiTR,

I tried your CONTEXT_VIEW_MODES module.
I found it to be WONDERFUL !!!!! I invite to urgently commit it in the public Drupal part.

In addition with Breakpoint + Context Breakpoint modules, there's a really good tool to produce adaptative websites without coding.
Works fine with Bootstrap sub-themes.

Ups!, is it really working for you?

Hi Jordi,

the release https://www.drupal.org/files/issues/context_view_modes.zip works fine for me.

I'm going to agree that this should be included with context as a core reaction. View modes are an integral part of Drupal even though they may not be out of the box. Custom modules create their own view modes and with the ability to easily create them through Display Suite or Entity View Modes, it's a step away from needing a view mode reaction in context. Since Drupal does have Full Content and Teaser available out of the box, it makes sense to insert this into contexts core to be extended by all entities.

"If" view modes were not a part of Drupal core, I would agree with the logic to leave it as a contrib module, but since view modes are a part of Drupal Core, I firmly believe context should react on them.