The create PDF can be extremely useful to generate PDF documents from web pages or URLs, and display them as in line content or as attachments.
Here’s the step by step recipe on how to install this plugin.
2) Upload the complete createPDF folder including the 2 sub-folders included in the plugin (“wkhtmltopdf” and “examples”) to the cmsAdmin/plugins folder on your server.
3) Activate the plugin and click on "Test Server Requirements". If you encounter errors, there are some required server libraries listed in the readme file that came with the plugin, and you may have to work with your server admin to get them up and running. If you still have issues, post the specifics on the plugins forum and IT will help to resolve them.
NOTE: I had to adjust the server path to my viewer_functions.php by removing one of the ../ from the path. I also encountered a “No input file specified” error in the PDF output test, but that was resolved by Dave’s first suggestion below.
4) After you’ve eliminated all the errors, test some of the examples in the examples folder
5) You can run the example code from viewers in another directory, but you’ll have to adjust the path to your viewer_functions.php file
When I ran the example code, the URL as inline opened as a web page in FF(3), IE(8), Safari (4), or Chrome (7) and look really good. If I ran the URL as attachment code, it downloaded a PDF that also looked good.
No matter what I tried, I could not display an html or output PDF, either as inline or as attachment. The results all showed "no input file specified" as the only text in the resulting PDFs.
Dave Edis from Interactive Tools came to the rescue. He said,
“The plugin creates temp .html files and your server was redirecting *.html to *.php so the plugin couldn't find it's temp .html files. Add this line to your .htaccess so requests will only be rewritten if the .html file doesn't exist:”
RewriteEngine on RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteRule ^(.*)\.html$ $1.php [nc]
Another issue that I came across (V 1.09 - 2019) was that if any of the links on my page were broken, I'd get a 'content not found' error when I sent the convert to pdf request.
The next issue involved creating a PDF from a URL that was protected by a membership plugin password, all I could get was a PDF of the login screen, even if I was logged in.
Again, Dave came to the rescue, he reminded that in the advanced topic section of the readme file about creating a PDF of the page that’s currently being viewed in a browser. It suggests:
To create a link that shows the current page as a PDF do the following:
LIST VIEWER First, create a link on your list viewer to the current page, but with ?pdf=1 as the url. Example:
<a class="your_css_class" href="?pdf=1">CLICK TO CONVERT THIS PAGE TO A PDF</a>
Another anomaly (this one on Bluehost ising V 1.09 in 2019). I found that if I was trying to convert an index.php page to aPDF, I'd have to add index.php to the link above, or I'd get content not found errors:
<a class="your_css_class" href="index.php?pdf=1">CLICK TO CONVERT THIS PAGE TO A PDF</a>
DETAIL PAGE This gets a bit more complicated. You'll need to call the specific page and record number, like this:
<a class="your_css_class" href="http://www.your_site_URL/your_detail_page.php?pdf=1&<?php echo $your_tableRecord['num'] ?>">CLICK TO CONVERT THIS PAGE TO A PDF</a>
Next, for either, add this code to the top of the viewer after the get records code block:
<?php if (@$_REQUEST['pdf']) { createPDF_fromOutput('inline', 'example.pdf'); } ?>
Another anomaly (this one on Bluehost in 2019). I found that if I was trying to convert an index.php file, I'd normally just use the link:
ONE (OR MORE) OF MY SERVERS WON'T SUPPORT THE PLUGIN If you have site(s) (client(s)) on a server or servers that don't meet the requirements of this plugin, but you do have even one server that does support them, you could use that server as a “proxy server” (host) to do all of the heavy lifting required. (V1.01 and above) This approach will work with one "host" and any number of "clients".
Here’s how to set up the "host", "client" relationship:
1) Upload the createPDF plugin as above, and enable the plugin on both the site that you’ll be using as a server (host) and the site(s) that needs to be “served” (client)
2) In the createPDF.php plugin on the “host” set the values on these two lines:
$GLOBALS['CREATEPDF_PROXY'] = true; $GLOBALS['CREATEPDF_PROXY_PASSWORD'] = 'enter_your_own_password_here';
NOTE: The password can be anything you like, just make sure that it is identical on the “host” and on any “client” sites.
3) In the createPDF.php plugin on the “client(s)” set the values on these two lines:
$GLOBALS['CREATEPDF_PROXY'] = ‘http://url_to_your_host_server/cmsAdmin/plugins/createPDF/createPDF_proxy.php’ ; $GLOBALS['CREATEPDF_PROXY_PASSWORD'] = 'enter_your_own_password_here';
4) When you click on "Test Server Requirements", in the cmsAdmin/plugins menu on the "client" site, you should see an indication that you are "Using Proxy" and, if you haven't made any errors when typing in the required information in steps 2 and 3, you should see "Passed" next to the "Test downloading content from remote URL" and Test downloading content from proxy URL" tests.
After that, any time you implement a create pdf request on the "client" it should execute as planned.
CHANGE THE COLOR OF PAGE BACKGROUND TO WHITE FOR THE PDF
Dave Edis offered this idea..
He said, since the page is reloaded after the request to create a PDF is executed, you could replace the opening body tag with something like:
<?php if (@$_REQUEST['pdf']): ?> <body style="background-color:#FFFFFF"> <?php else: ?> <body style="background-color:#569F00"> <?php endif ?>
HIDING THE "CLICK TO CONVERT THIS PAGE TO A PDF" LINK ON THE PDF
You could also replace the createPDF execution link with something similar, like this for a list page:
<?php if (@$_REQUEST['pdf']): ?> <?php else: ?><a class="your_css_class" href="?pdf=1">CLICK TO CONVERT THIS PAGE TO A PDF</a><?php endif ?>
Or, for a detail page:
<?php if (@$_REQUEST['pdf']): ?> <?php else: ?><a class="your_css_class" href="http://www.your_site_URL/your_detail_page.php?pdf=1&<?php echo $your_tableRecord['num'] ?>">CLICK TO CONVERT THIS PAGE TO A PDF</a> <?php endif ?>
You can also add some parameters to the end of the convert code to make the PDF open in specific ways.
To make the reader open at 100% magnification, with scroll bars, a toolbar and a navigation pane, I used:
<a class="small" href="http://50.6.159.105/about.php?pdf=1&<?php echo $resumeRecord['num'] ?>#toolbar=1&navpanes=1&scrollbar=1&zoom=100">CLICK TOCONVERT THISPAGE TO A PDF</a>
You can finds other useful parameters in the PDF at:
http://www.thecmsbcookbook.com/downloads/pdf_open_parameters_v9.pdf
CAVEATS: Be careful when using in line styles to change font sizes. They can wreak havoc with rendered PDF.
I thought that I was being very cool and used a special class to change the font size in some links when displayed in the PDF and spent the better part of a day finding out that this was the cause of my PDF font sizes coming out much smaller than I wanted them to.
THINGS LEARNED FROM IMPLEMENTING THE createPDF PLUGIN ON THE COOKBOOK SITE
Aside from the information above, I found out a few things that were specific to my implementation. I was using highlight_string and was having issues with links in the PDF that were offset from the text that they were supposed to be connected to.
I was originally using
<?php $recipe = wordwrap($record['recipe'],140) ; $recipe = highlight_string($recipe) ;
?>
to render the recipes on my list pages.
and for my detail pages.
<?php $recipe = wordwrap($table_of_contentsRecord['recipe'],140) ; $recipe = highlight_string($recipe) ;
?>
Dave Edis took a stab at solving the issue. He said:
It looks like highlight_string() replaces all the spaces with . My guess is something about the long lines was causing problems with the PDF conversion.
This code will switch them back to spaces:
<?php $recipe = $record['recipe']; $recipe = highlight_string($recipe, true); $recipe = str_replace(' ', ' ', $recipe); $recipe = wordwrap($recipe, 140, '', true); print $recipe; ?>
I needed to modify things like this to get the detail pages to render correctly:
<?php $recipe = $record['recipe']; $recipe = highlight_string($recipe, true); $recipe = str_replace(' ', ' ', $recipe); // $recipe = wordwrap($recipe, 140, '', true); print $recipe; ?>
User MickC offered this code to rename the PDF that's created to something more meaningful then example.pdf.
In it's current form it creates the PDF from "your_detail_page" as an attachment and the creates file name for the PDF from the value of "field_1" and "field_2" of the table "your_table". To create the document as an inline PDF, just change 'attachment' to 'inline' in the last line of the code.
<?php require_once "lib/viewer_functions.php"; ?> <?php $filename= $your_tableRecord['field_1']."-".$your_tableRecord['field_2']; $num= $your_tableRecord['num']; $url = "your_detail_page.php?".$num; $data = createPDF_fromUrl($url); createPDF_display('attachment', $data, $filename.'.pdf'); ?>
You can download a PDF test page that implements some if statements to change various parameters on the resulting PDF from:
http://www.thecmsbcookbook.com/downloads/pdftest.zip
My next issue (as yet unresolved) was using named anchor tags within the pages and having them operate correctly in the rendered PDF.
I'll post a solution as soon as I have one (or one of my subscribers sends one along).
|