Allow multiple print view modes

The teaser mode is used when the node itself is displayed as a teaser (such as the default frontpage list).

As to allowing the view mode to be overridden.. sorry no. I'm sure there's a very specific case in which you need this, but I'm not interested in complicating the module with solutions for all the edge cases.

The teaser mode is used when the node itself is displayed as a teaser

I don't see any way actually use that outside the mail form. I'd like to be able to expose the same node to users directly on the website in two different print formats. If that's currently possible, can you please explain how? If not, is that really such an edge case that it's not worth a simple 3 line patch?

It's enough of a edge case that the module exists for 6 years already and this is the first request I see for a configurable view mode (granted that view/build modes have only been around for somewhat less than that).

You're right that the module doesn't allow you to change view modes. That's by design. And the way this is being done in the patch is not the best way.. It's possible for nodes to have parameters, and not that uncommon. The current 3-line patch would set random view modes whenever some node took URL parameters.

To do it in a way that doesn't break things, you'd need to use a slightly different path: print/view_mode/nid would be my suggestion.

However - again - this is in my view a edge case. Drupal core doesn't allow you to set custom view modes based on paths, so I'll follow it's example.

To do it in a way that doesn't break things, you'd need to use a slightly different path: print/view_mode/nid would be my suggestion.

Are you suggesting that approach may be accepted, or simply suggesting that would be a better patch to also get rejected? If the former, please set the status to "needs work."

I still think that this is not relevant to the general case, but if you create the patch, share it here.. If I'm proven wrong, I'll integrate it.

I'm currently in a situation where it actually would have been nice with the possibility to change display by option in settings page and/or by url. I'm a bit surprised that there haven't been more requests for this.

My situation. My content type use large pictures. The general design idea is to use large pictures in order to inspire. It's actually very important for this kind of website (which I'm not allowed to present until later). Large pictures to inspire, while the important stuff still is in the text (in combination with pictures).

However, when printing node, I would like smaller pictures, as everything fills up a bit different. Since pictures only have fixed width, but not height, I can't resize them with html/css which otherwise would be an option (though not preferred).
There are two main reasons for smaller images when printing node. First, they simply take to much space. Some expand on more than one paper, which looks weird. Second, at this point the user already is inspired, and the text itself is so much more important. The picture is still there since it would look doll and in some cases it would be rather tough to accomplish anything without the picture, but the focus is not on the picture anymore.

Don't know if this makes sense to you, but I think that in a lot of cases this is logical. You want to focus on content when you print a node, and that may not always be exactly all the stuff that you get in normal case. Of course, a simple solution would be to hide a lot with display: none; (which I have, quite a lot), but a even better solution (better performance, more optimized) would be to actually don't load the stuff. This wont do that much difference when hitting a couple of thousands unique visitors a week, but when/if that traffic increase (let say 500 000 unique visitors or more), then small things counts as well.

You already have that.. The module uses it's own view mode.

Go to your current type, enable the print view mode (Drupal core has all extra view modes disabled by default), and select which fields you want in the printer-friendly version. Regarding those images, if you use image styles, you can set one style for the full mode and another for the print view, also.

The request here was something completely against the spirit of this option: to change view modes via URL arguments.

Sweet, thanks!

Still have to get use to Drupals "clicking madness" (settings, settings, settings...) :)
Yes, was thinking about using image styles to do it.

Thanks for the help!

What you can't do with the current implementation is have two view modes for print. For example, if you decided to offer a second print option with the large images alongside the small image print option, that's not possible.

Sure it's possible.. The template is PHP. In theory you could run another instance of Drupal out of it. In practice, that is not something this module is supposed to do. If someone makes a module that allows you to switch view modes based on command line params, I'll try to make sure that this module supports the output of that module.

You already have that.. The module uses it's own view mode.

But this doesn't seem to take into account entities that are not nodes? I have tried dumping $vars in various preprocess template functions and not one says its in Print view mode, and the theme hook suggestions under preprocess_page do not work. It is making it really difficult to control the print experience and theme it up appropriately.

No, support for non-node entities is based on asking Drupal to render the full page using methods that do not support setting a view mode. I haven't had the time to experiment with entity_load instead of node_load to assess what's the impact of generic entity support.

But that's the different issue you raised (#1647452: Non-node Entity support?) and why I set it to 'postponed' and not 'fixed'.

I too have the need for multiple print modes for a given node type. in my case, it's for PDFs and it's not from the URL but via the api, ie. the print_pdf_generate_path function.

this patch adds an optional argument to that function allowing you to set a display mode. the arg gets passed along the function "chain" to the point of the rendering function. if the argument is left off, it simply defaults to the "print" mode, as it did before, so no implications for existing code.

this patch could be built upon to do the same in the other(s?) API calls, as well as integrated with the above patch for the URL argument (though i agree with the point in #4 suggesting a different order for the arg).

fwiw, i don't really think these are edge cases, or if they are, i consider this code benign 'nuff to be worthy of the above improvements and committing, though i'll refrain from doing any such improvements myself until/unless the maintainer indicates a willingness to commit....

cheers,
shiraz

This seems useful. I won't be merging it into version 7.x-1.x, but if you're willing to extend this to the other formats (mail and epub), I'll try to commit this in time for 7.x-2.0.

I won't be changing any of the hook_menu() to support this from the URL for now. But with this in place, it should be trivial for others to do this in their custom modules.

I also have been needing a solution to be able to print different view modes for the same node. I don't know which is the best way to achieve this, but it will be for sure a great new feature to the print module.
I disagree that this issue was not risen before, since there are a lot of similar/related posts in the issue queue that could be easily solved by finding a solution to this.
I can help coding/testing patches.

I've committed a modified version of #14 to git (http://drupalcode.org/project/print.git/commit/7fe7353).

Restoring this to original state.

jcnventura (as in the wrestler?),

thanks for committing!

Hi jcnventura, thanks for your work !

you said "got o your current type, enable the print view mode", but can't figure out how to do that.
the only way i found to make this worke is to set 'custom settings' => TRUE, in print_entity_info_alter

am i missing something ?

Go to Manage Display > Default
At the bottom of the page, you have Custom display setting tab
Inside it you check the print mode and save.
A new tab named Print will appear beside Default and Teaser ( top right ) where you can set the display for print mode

Cheers

With advance of Display Suite ans Panelizer modules it makes a lot more sense changing approach to view modes. Instead of supplying one "Print" view mode this module could provide settings form in which user could select which view modes will be print view modes. Does this sound reasonable?

My use case is printing node with entity references. I would like to have two print links - "print node" and "print node and related nodes". Setting up two view modes and creating a link is a breeze.

mansspams, the patch in #1 allows what you've described. Having two print view modes was rejected as an edge case, but you can still apply the patch to your own local copy.

Rerolled patch against latest dev (7.x-1.x)

Easy way without patching.

Create a custom module: print_custom

function print_custom_entity_view_alter($build, $type) {
        if ( $build['#view_mode'] != 'print' ) return ;
	$build_mode = arg(2) ;
	if ( empty($build_mode) ) return ; 
	$build['#view_mode'] = 'my_view_mode' ;
}

I am looking for multiple print buttons say "print this page: normal" and "print this page: large" which are usually found on some *.edu sites for accessibility.
Is this thread right for what I needed? or is it separate feature.

@Erik Seifert I think the suitable hook for changing the view_mode (and therefore set yours) is hook_entity_view_mode_alter

The patch from #24 gave a 404 combined with the latest dev release of the print module ... Here's a re-roll.