I'm using some embedded PHP to grab and output data into a page. For some reason, only the table header generated by the following code shows up in the printer friendly output.

<?php
include('includes/mytable.php'); //this is where the mysql calls are
$mytable = get_mytable(drupal_get_title());  //pass title so we know what to return
$output = theme('table', $mytable['header'], $mytable['rows']);  //let drupal make the table
return $output;
?>

This works fine for the normal display, but not for the printer friendly version. Can anyone tell me why the table rows don't get included in the printer friendly version or what I can look for that may be causing problems?

Any guidance is much appreciated.

Thanks

Comments

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Active » Closed (fixed)

Hi,

The following code worked perfectly for me in Drupal 6.1 + current print dev. The 

<?php
$header = array('1','2');
$rows = array(array('3', '4'), array('5','6'));

$output .= theme('table', $header, $rows);
return $output;
?>

You can see it 'in action' at http://www.venturas.org/6/print/104. I would guess it's something local to your site.. Check the printer-friendly page's source in your browser and see if the rows are there (culprit would be your CSS). Then try to add a var_dump($output); in your code before the return. When displaying the PF page, the debug info will be printed in the beginning of the page. If the rows are not in this dump, then it must be your theme's theme_table() function.

João

ml1’s picture

ml1 commented
Status: Closed (fixed) » Active

var_dump($output) shows the output in the /node, but still doesn't show in /print. I've tried using several themes, including Ability, Bluemarine, Garland, and Marvin.

Since I'm fairly new to drupal, I guess I don't understand why it is rendered correctly in /node, but isn't rendered correctly in /print, regardless of the theme_table() function.

jcnventura’s picture

jcnventura
Primary language English
commented

Thanks for the info.. Sorry for trying to close the issue.

Reading your code in more detail, I think that the problem is precisely the fact that you pass the current page's title as an index to the contents that the get_mytable() function should return..

This is something I can test, but I am pretty sure that a var_dump(drupal_get_title()) will return different values in the normal page and in the print page. I will try to see if I can change this..

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Active » Needs review

Hi,

I think I got it. Can you please test the following patch? I would like to know if it solves your problem before committing it to the CVS repository.

--- print.pages.inc
+++ print.pages.inc
@@ -340,6 +340,7 @@
     // Access is denied
     return drupal_access_denied();
   }
+  drupal_set_title($node->title);

   //alert other modules that we are generating a printer-friendly page, so they can choose to show/hide info
   $node->printing = true;
ml1’s picture

ml1 commented

Sweet! That works perfectly.

edit: Btw, if it matters, I was not calling var_dump(drupal_get_title()), I was calling var_dump($output) after get the return info from get_mytable. The title was used to do a look up from another database and fill in a table to display based on the node's title.

jcnventura’s picture

jcnventura
Primary language English
commented

Yes, and your lookup was the problem. Since the node contents of the print page gets built during the call to print/nid, the call to drupal_get_title always returned 'Printer-friendly'. The added line above sets the title to node title. I don't know if there's any difference but that's the best that can be done anyway.

I will commit the line above to the dev version shortly. And since it's been a month since I did a 'stable' release, I will probably create a 1.0-rc2 at that time also.

João

jcnventura’s picture

jcnventura
Primary language English
commented
Status: Needs review » Fixed
ml1’s picture

ml1 commented

Thanks for figuring that out and fixing it so quickly.

Anonymous’s picture

Anonymous (not verified) commented
Status: Fixed » Closed (fixed)

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