Link directly to a PDF - to make it open in the browser

Author Message

Jordan Hirsch

Thursday 01 July 2010 2:36:38 pm

I'm trying to construct a link to a binary file (a PDF) that's in content class File. When I use the standard method of constructing the link via "content/download" the browser prompts me to download the file. However, I need the PDF to open in the browser window - this is the behavior I see if I link to a PDF file directly.

I tried to link directly to the file using this method:

href={concat('/', $attribute.content.filepath)|ezroot()}

But I get a 404 on the resulting link (which looks like /var/sitename/original/application/etc.) In addition, most of the files in my var folder don't have file extensions, so I'm not sure that the browser would even know what to do if I linked directly to one of the files (Firefox in particular tends not to recognize PDFs properly without their extension, at least I've seen that behavior before).

Is there a recommended method to link directly to a binary file without using content/download to force the browser to download the file?

Thanks!

UPDATE: I tried setting the PassThroughSettings in file.ini, but it didn't seem to have any effect - the PDF still downloads instead of opening in the browser when I use the content/download link.

[PassThroughSettings]
ContentDisposition[application/pdf]=inline
ContentDisposition[application/x-pdf]=inline

I resolved the 404 when linking directly to the file in var/ by changing my RewriteRules, but since the vast majority of files in that folder are missing their file extensions, the browser doesn't understand how to open the file without ".pdf" at the end. Any idea how I can restore those missing extensions?

UPDATE 2: Apparently setting the ContentDisposition settings was sufficient, but for some reason the change didn't take until I cleared the cache through the admin, as opposed to command-line (not sure why). If you're curious about the missing extensions in the filenames, it's a known issue which was supposedly resolved in 4.0, but I think it is still out there, I just haven't nailed down the exact circumstances to reproduce. I was able to solve it by running this script, which got me most of the way there, and then running the following SQL statement (the script changed the file names correctly but did not update every record in the ezbinaryfile table):

 UPDATE ezbinaryfile SET filename=concat(filename, '.', SUBSTR(original_filename, -3)) WHERE (filename NOT LIKE '%.___') AND (original_filename LIKE '%.___');

That SQL copies the extension from the original filename into the new filename field (only if the original filename had an extension of a . and then 3 characters and the new filename does not already have that).

Me: http://jordan.teamhirsch.com
My blog: http://wiredformusic.blogspot.com
My other company: http://thinkimprov.com
eZ Certification: http://auth.ez.no/certification/verify/402488
eZ Award: http://ez.no/company/news/ez_awards_2007_prize_winners

Conrad Decker

Saturday 03 July 2010 6:12:16 am

Hey Jordan!

I generally have three options for content creators on how they want to handle showing pdf files. One, as you mentioned would be to force a download of the file using the content/download module, the second one is forcing the browser to view the file, rather then forcing the download. I do this by linking directly to the file, however I notice the way a browser handles the file at that point is completely different on all browsers and is even handled differently on different operating systems.

It sounds like you were able to utilize the content/download functionality to actually view the file in the browser, is that correct? What OS/Browser combo did you get that to work on?

One other option that I thought I'd at least mention is using the Google PDF viewer to ensure the browser shows the PDF online rather then forcing the download. This is a nice way to ensure that your site is consistent across all browsers and OS's. I do this by constructing the link using the .filepath property, but I wrap it in a link to the Google PDF viewer. The final link ends up looking like this - http://docs.google.com/viewer?url='http://domain.com/var/path/to/file.pdf&embedded=true&width=700&height=1050'

And if you're feeling really froggy, you can even open that as an iframe directly in a modal window on the site when the link is clicked. It's a nice little addition to any site.

Hope that's somewhat helpful to you or someone else.

Jordan Hirsch

Saturday 03 July 2010 9:34:27 am

Hi Conrad!

Thanks a million for that Google PDF viewer tip - that sounds like an ideal solution that I will definitely be using in the future. Consistency across browsers is key for most clients when it comes to opening PDFs. This client in particular seemed to care mostly about Firefox, so I was doing my testing on FF 3.5 on Win XP SP 3. It looks like once I added the PassThrough lines to file.ini, FF started opening the PDFs in the browser window and not showing the "save file" dialogue box, even though I'm still using the "content/download" link structure (which is nice, because using that makes sure that eZ enforces permissions, as opposed to linking directly to the PDF in the var/ folder).

All that stuff about missing file extensions really threw me off, but in the end it turns out I had the fix very early on, I just hadn't cleared the cache fully enough (sometimes the command line just doesn't do it, I guess) to see the change.

Thanks again for that Google tip - that's a great solution!

Me: http://jordan.teamhirsch.com
My blog: http://wiredformusic.blogspot.com
My other company: http://thinkimprov.com
eZ Certification: http://auth.ez.no/certification/verify/402488
eZ Award: http://ez.no/company/news/ez_awards_2007_prize_winners

Conrad Decker

Tuesday 06 July 2010 3:34:01 am

Oh wow, that's interesting. I hadn't even thought about how linking directly to the PDF in the var folder would bypass the normal permissions in place with eZPublish, but that does make a lot of sense. I'll have to take a look at file.ini and the PassThrough directive...thank you for the pointer.

Definitely let me know about the Google PDF Viewer and if you have any questions on it's functionality. I agree it's a pretty smooth solution with all of the browser/os consistencies!

Peter Keung

Tuesday 06 July 2010 11:01:57 am

I've had good experiences using the Google Docs Viewer... except for this annoying IE8 problem: http://www.google.com/support/forum/p/Google+Docs/thread?tid=22d92671afd5b9b7&hl=en

http://www.mugo.ca
Mugo Web, eZ Partner in Vancouver, Canada

Conrad Decker

Tuesday 06 July 2010 7:19:42 pm

Thanks for the input Peter, I've actually run into that issue as well, but only when trying to show the viewer in an iframe.

My solution was initially to open the pdf viewer in an iframe, within a modal window, but I ran into the issue that you pointed out in that posting. Apparently the doc viewer doesn't provide a compact privacy policy which is a standard in IE. I was actually disappointed to read that Google left something relatively simple out of their implementation. I understand not supporting older versions of IE, but unfortunately this makes their viewer completely non-functional in IE in an iframe.

Ah well, what I ended up doing was a browser check using jquery. If the browser was IE, I opened the pdf viewer in a pop-up window, if not, I used pretty photo to open the viewer in an iframe embedded into a modal window. Here's the simple js if anyone is interested.

UPDATE: moved the code to pastie...

http://pastie.org/1033684

Powered by eZ Publish™ CMS Open Source Web Content Management. Copyright © 1999-2014 eZ Systems AS (except where otherwise noted). All rights reserved.