Views 2 Support

Hi,

I don't think that Views support will happen in the near future.. I need either to feel the need for it myself, or someone that is really interested ($$$) to sponsor that project.

João

That looks a lot like a wishlist for the views support. I forgot to mention option 3: someone else contribute a patch :)

Now seriously, there's no need of a weird action there.. Just calling the URL print/PATH will generate the printer-friendly version of any path under Drupal.. However, since I don't know the technical details of what you're asking, I have no idea if that info helps or not.

João

You can add the pdf stuff pretty easily by creating the correct view.tpl.php and modifying it. I did this recently by adding the nid field to the view and then detecting for it and adding in a l(t('pdf'),'print/'. $nid);

Save this dude some time via this easy way of doing the same thing :)

Can you expand on that a bit more? Maybe paste your code and a bit of how-to. As far as I can see it, this is a top priority to have views integration, one way or another.

Sure can. You just create a well-formatted template file in your theme that's named correctly for the view it should be associated with...

So, I created a file called views-view--print-activation-codes.tpl.php (cause my view is called print-activation-codes)

and put this in it

// $Id: views-view-table.tpl.php,v 1.6 2008/06/25 22:05:11 merlinofchaos Exp $
/**
 * @file views-view-table.tpl.php
 * Template to display a view as a table.
 *
 * - $title : The title of this group of rows.  May be empty.
 * - $header: An array of header labels keyed by field id.
 * - $fields: An array of CSS IDs to use for each field id.
 * - $class: A class or classes to apply to the table, based on settings.
 * - $rows: An array of row items. Each row is an array of content
 *   keyed by field ID.
 * @ingroup views_templates
 */

endif;

endforeach;

endforeach;

endforeach;

			if ($field == 'nid') {
			  print l(t('Print'),'print_activation_codes/'. $content);
			}
			else {
			  print $content; 
			}
			

The part that I changed from the file as Views2 looks to generate is this

			if ($field == 'nid') {
			  print l(t('Print'),'print_activation_codes/'. $content);
			}
			else {
			  print $content; 
			}
			

So what I did is include the nid in the display and then I trap for it and print a link to the print view (or at least I did it to some other link but you could make it go to the print link path). If it's not the nid it prints the table-cell as it normally should.

Another item for the views support requirements (from #439458: Integration with Node Hierarchy):

Given a list of nodes in a view, provide the print-friendly page containing all of those pages.

There are a couple of workarounds which enable you to 'nudge' the theming in the right direction, although not gain complete control:

1) If you include your main CSS file in print.tpl.php most of the formatting still works on the print page, but with the same simple layout.

2) print arg(0) returns the name of the view, so you could use this in an if() statement to include a CSS file specific to each view. This could be used for hiding (display:none) certain things or adjusting the page width etc.

Cheers,

Neil

You can also use a request_uri() to detect if it is print, pdf or email and then include a stylesheet accordingly e.g.

<?php
  $uri = request_uri();
  if(strpos($uri, '?q=printpdf/')):
?>

  <link href="/sites/all/themes/gta/gta-pdf.css" media="all" rel="stylesheet" type="text/css">

<?php endif;?>

You can easily pdf any view by just sticking printpdf/ in front of the view's url. i.e. www.example.com/printpdf/viewpage

you can then make a block with the above url, and have it show up on the view's page only that says click here for PDF version

that's all. simple effective fix to get a pdf of most views.

@akolahi,
how do get the pdf version link to show up on a view? At the moment i can only get it to show on nodes.

Your solution sounds like a quick and easy fix for printing views.

Ok. I just reread your suggestions. It sounds like you hard code the URL into the block and when placing the block on the view you include text to the effect of 'click here for pdf version'. Is this text IN the block or the TITLE of the block and does it matter?

Thanks

Either i'm doing something wrong or my theme is broken. The block does not show on my view.

@akolahi,

I couldn't get the block to show in a view, so i tried including a link in the view's footer. The link shows. But adding printpdf before the view results in a page not found.

Did you install the special dompdf tool? See http://drupal.org/node/306882
I had a similar problem and that is solved now. I still have issues with printing a pdf of a view with multiple columns (they all get printed one on top of the other!), but you should be able to solve your problem with help from that page.

Warm regards
Jaya

TomSherlock,

if you place the link in a block, you need to go to the block admin page to make sure the block is visible on the particular view's page. Basically you want to the block to only show on that page and you need to tell the block the url of the view you would like for it to show up on.

Yes, I have the dompdf.

Good chance I'm interpretting this incorrectly, but I hope this is the right place to ask this:

I've installed the module and it looks and works great on content added from content types.

I've got a standard view that generates content based on fields and filters, nothing to out of the ordinary. On these pages, the printer-friendly version does not display.

In the option: Show link in system (non-content) pages: I have checked "Show on every page except the listed pages." I have nothing listed in the exceptions...shouln't it be showing up on the pages that are generated with views?

Am I overlooking something? Appreciate any help.

- I was a drupal newbie a few months ago then got put on another project, now just put back on this so if this is the wrong forum...I'm catching back up. Thanks

Yes, the links should be showing in all the views pages now.

I have everything working for print, email, and pdf at the node level -- the print icon/text, email icon/text, and pdf icon/text shows up.

On all my views or panes or panels, only the print icon/text shows up.

I am running:
Drupal 6.15, dompdf, Print 6.x-1.10

I checked to make sure the user permissions were set.
I checked the print module settings and they all look okay.

Where should I look next for any issues?

bekasu

subscribe

subscribing

subscribe, this code will help me, thanks.

subscribe

subscribe

You know, I had real problems in system pages with the Print/Email icons appearing all over the place (eg in $help), so I cheated in certain views and added the following PHP in the view footer to get a print friendly view

<span class="print_html">
  <a rel="nofollow" onclick="window.open(this.href); return false" class="print-page" title="Display a printer-friendly version of this page." href="/print<?php print $_SERVER['REQUEST_URI'']; ?>">
    <img height="16" width="16" class="print-icon" title="Printer-friendly version" alt="Printer-friendly version" src="/sites/all/modules/print/icons/print_icon.gif">
  </a>
</span>

Not very elegant, but works

Following snorkers train of thought, I added this to my View's row template (views-views-fields.tpl.php)
Seems to do it too, just make sure you have the PATH module initiated.

<?php
    if (module_exists('path')) {
        $alias = drupal_get_path_alias($_GET['q']);
        $class = explode('/', $alias);
		?>
		<span class='print-link'>
			<span class="print_html">
				<a href="<?php base_path() ?>print/<?php $class[0] ?>" title="Display a printer-friendly version of this page." class="print-page" onclick="window.open(this.href); return false" rel="nofollow">
					<img src="<?php base_path() ?>sites/all/modules/print/icons/print_icon.gif" alt="Printer-friendly version" title="Printer-friendly version" width="16" height="16" class="print-icon" />
				</a>
			</span>
			<span class="print_mail">
				<a href="<?php base_path() ?>printmail/<?php $class[0] ?>" title="Send this page by e-mail." class="print-mail" rel="nofollow">
                	<img src="<?php base_path() ?>sites/all/modules/print/icons/mail_icon.gif" alt="Send to friend" title="Send to friend" width="16" height="16" class="print-icon" />
                </a>
            </span>
            <span class="print_pdf">
            	<a href="<?php base_path() ?>printpdf/<?php $class[0] ?>" title="Display a PDF version of this page." class="print-pdf" onclick="window.open(this.href); return false" rel="nofollow">
                	<img src="<?php base_path() ?>sites/all/modules/print/icons/pdf_icon.gif" alt="PDF version" title="PDF version" width="16" height="16" class="print-icon" />
                </a>
			</span>
		</span>
		<?php
    }
	?>

subscribe.

Would be great if you could print a view in full whilst the screen one shows with a pager.

I'm also interested in this.

Looking at some of the comments here (#10 in particular) I've got it working (although not tried a real situation yet).

I created a view page called view_invoices and added to the view footer the following code:

<a href="/printpdf/view_invoices" >click here for pdf version</a>

Users must have permission to "access PDF version" otherwise it doesn't allow access.

The only small issue I have is that, if the user has permission to "administer views", then the links for edit/export/clone appear in the PDF file.

My footer link also appears in the PDF file.

Views 3 is in alpha3, http://drupal.org/project/views with a security patch to Views 2 and Views 3 alpha just out yesterday. Just chiming in, realizing that this issue is currently in postponed mode.

@#25
You can try the following as an alternative:

<?php 
if (true === module_exists('print')) {
    print print_insert_link();
}
if (true === module_exists('print_mail')) {
    print print_mail_insert_link();
}
if (true === module_exists('print_pdf')) {
   print print_pdf_insert_link();
}
?>

Well here's a quick and simple implementation of this. But it's so simplistic, it can't be configured per individual view, just on or off for all. That would need some kind of select widget to choose specific views, or it could be done via the paths.. anyways, this code scratched my own itch so i'm done with it ;)
oh and there's two other changes: the first changes the print.css to (imho) really improve the looks of the print and pdf versions. The other one - well the comment says it all.

The $node_type static variable is there for a reason. By removing it, you destroy the ability to display links in individual comments.

Also, instead of

  elseif ($is_view) {
    return variable_get('print_mail_views_link_visibility', 1);
  }

It should be

  elseif (($is_view) && variable_get('print_mail_views_link_visibility', 1)){
    return PRINT_ALLOW_NORMAL_LINK;
  }

The $node_type static variable is there for a reason.
Well there might be an intention, but the way it is used in the code does not make clear sense to me. I've grepped the code for "$node_type" before and tried to make sure that changes is functionally equivalent. I am looking at that code right now and still see no use of that variable:

print_mail.module (only lines containing $node_type):
<?php
  if (!empty($args['node'])) {
    static $node_type = FALSE; // WHY should it be static? variable 
    if (isset($node->type)) {
      $node_type = $node->type;
    } //$node_type is either set to $node->type or FALSE
    elseif (isset($args['type']) && ($args['type'] == 'comment') && isset($node_type)) {
      $print_display_comment = $res ? intval($res->comments) : variable_get('print_mail_display_comment_'. $node_type, PRINT_TYPE_COMMENT_LINK_DEFAULT); //$node_type used in string only if $node->type set
    }
?>

....RingTFM @ http://www.php.net/manual/en/language.variables.scope.php... thinking...

okok i got the idea. DOH! some code still looks stupid you must confess that. L0l ;)

..and i guess this one is additionally required to make PHP stop complaining..

This seems to be OK just from looking at the code.

I'll need to test it myself, but if others can provide their own reviews/opinions, it would be great.

I've become confused, probably not anyone's fault but mine :) But...

I'm trying to figure out what this patch/these patches do -- do they...
(a) allow for enabling the display of print/mail/pdf icons/links on Views-generated pages (or something like this),
(b) provide an alternative or some kind of fix for the issue (that I was having, anyway) where you can't just do www.example.com/print/viewpage-urlalias (the view results won't be there), or,
(c) something else entirely?

And/or, am I missing something? Is the fix for (b) following the suggestions put forth in #4 or #6 above, and the patch(es) here simply do (a)? Or...

Sorry for my confusion, and thank you to anyone willing to clarify for me!

@35:
well i wasn't aware (and haven't read) this bug report until implementing my patch.. it actually does a) and doesn't use any additional template (which is actually not the right way to go, but i needed this quick and dirty hack to print out my website ;)
maybe you can temporarily backup your current print module directory and test this patch?

alisonjo2786:
Actually this patch doesn't do much that the module isn't already able to do (I still have to take a look at the nodes embedded in views part).

The module has been able to support printing the contents of a view for a long time now (see for example the reply in #10 of this thread). This patch simply makes it easy to start showing the PF links in all views. Without this patch you have to manually add the paths of your views pages to the system-pages-visibility settings.

So the answer to your question is: the module already supports a) and b) without this patch, it simply makes it simpler to configure a)

Now, my question to you is why are you saying that the www.example.com/print/viewpage-urlalias doesn't work for you?? Can you please create a new issue with a URL to the view that you can't generate a PF version?

João

Thank you, João, for your response, I understand all of this much better now.

As for the problem I was experiencing, after months of troubleshooting, research, and eventual resignation to the idea that what I wanted simply wasn't possible, an idea came to me that turned out to be the answer/solution I needed all along (agghh!!). Funny how banging your head against the wall never seems to produce good results, but re-examining an issue with fresh eyes often does... maybe someday I'll be smart enough to remember this before months go by!

It turns out that my view results weren't displaying on the printer-friendly versions of the pages because the views being inserted on those pages needed date arguments to display results, and I'd set things up to have the current node's creation time, or a date argument in the URL, if present, be the date argument for the view. Not sure if that made sense, I don't feel like I'm explaining this well, but the bottom line is that the views weren't getting the arguments they needed to generate any results. I now know how to fix this, so I should be all set.

Thanks for all your help and patience!

I've committed the #patches in #32 and #33 to git.

Any chance that we can get this ported and committed to the 7x version?

Thanks!

Isn't this as simple as:

- use the token module
- In views add the field Node: Nid
- In the settings of the field check "Rewrite the output of this field"
- Then add <a href="print/node/[nid]">Printerfriendly version</a> in the field below.

That adds the same link available on normal node pages

Patches #32 and #33 were having some undesired side-effects.. Reverting for now.

One thing I've noticed when viewing the print version of a view, not all of the PEP config options are honored, namely the list of URLs at the bottom of the page. It shows them whether the option is turned on or off. I definitely don't want them, but can't get rid of them (along with all the footnote numbers).

Actually, I really don't want to add a third visibility area.. Users are already having problems with the existing two..

Also, I am afraid I'll open the door to the patch requesting a visibility area for panels pages.

The plan is actually to reduce it to a single area that is predefined with "node/*" to mimic the current behaviour.