Affects all entities on page if condition is true

@michaelmallet,

Thanks for working on this. I have been giving it some thought. I like that you can target every entity on a page through the context configuration. I think this is a useful tool as many times you have views of nodes that need special alteration. For the single entity I have created two interface modules. One for nodes and one for users. I think this type of approach would work for the taxonomy terms as well. I don't want to get in to specific entity targeting in the reaction part of the this context plugin.

Attaching a patch that does not target a specific entity. It does enforce the CVM only when the viewed entity is the current menu item.
So on a node page that has a block with a few teasers, only the parent node view mode is enforced, allowing the teasers to preserver their view mode.

Cheers,
Dan

@zerolab,

Thanks for that patch. I just ran a quick test on the 3.x branch and used the contextual_view_modes_nodes module and set the view mode for a node on the node edit form. It did not effect the other rendered entities on the page. So, the functionality for getting at a single node is already in the module but it seems that the expectation would be that this is an option from the context page and not the node/edit page.

I do not want to default to just the node entity when the context condition is fired on a node page. Could you provide an option in the context reaction to target only the loaded menu object? A checkbox on the context reaction form might be enough to get by this UX/UI issue.

Thanks,

I've added a checkbox to the options form to control whether we want to restrict the view mode change to the page-level entity.

I've also done a little bit of tidying up around the page-level entity fetch; instead of menu_get_item, which doesn't work well if you're using a contrib module that overrides entity view pages (such as RESTWS), we're using menu_get_object.
(This has its drawbacks too, such as the need to pick the position of the entity ID in the path, but it seems to work decently enough, at least for a first pass.)

Please use this patch instead of #7. Turns out I wasn't fetching options from the right place.

Another fix for my patch; turns out that accessing it from a page that doesn't have a top-level node might cause it to falsely fall through to the next step. I'm removing that !empty check to ensure that this doesn't take place.