I’d like to create a static resource that opens a PDF. So, people link to the URL for the page, and a PDF loads. When create a resource, make it static, select the content type “PDF”, and make the content disposition “Inline”, then go to the URL, I get a browser error “Failed to load PDF document” (or similar message). If I change the dispostion to “Attachment” it works, but the PDF is automatically downloaded, not viewed in the browser.
It should work with inline. Opening the PDF in browser is the default browser behavior I believe. These are the settings I use for static pages/PDFs:
Title: Your Title
Template: (empty)
Resource Alias: your-alias
Published: Yes
Static Resource: link/to/.pdf
Resource Type: Static Resource
Content Type: PDF
Content Disposition: Inline
I think Lucy is correct for most browsers, but only if the user hasn’t changed the default browser settings. I don’t think there’s any way for you to override the browser’s selected behavior with downloadable files.
FWIW, I’ve seen some cases where Chrome will launch a .pdf file for viewing, then offer to download it after I’m done viewing it. I don’t know what the developer has done on the other end to cause that. It doesn’t happen very often.
The browser preference doesn’t have any effect here. Did you actually try and succeed using the “inline” setting? For me, inline doesn’t work; the PDF does not load at all.
You can make a PDF download rather than use the browser by using specific scripting to serve up the PDF; that’s what is happening when disposition is set to “attachment”. Using the header “Content-Disposition: attachment” does this, and also the newer HTML5 <a download="(filepath)"> instead of <a href="(filepath)"> is supposed to do that, although I haven’t tried it.
OK, I’ve done some testing on different sites, on different servers. It seems this is not really an issue of inline versus attachment at all. When inline doesn’t work, and I switch to attachment, and a file gets downloaded, but that file is completely blank. On one site, the PDFs load just fine, both inline (viewing in the browser as expected) and attachment (force download). On the other two sites, no PDF file gets loaded at all. I’m trying to find out whether this has something to do with the way media sources are set up (doubtful) or something else.
I also set up a Word Doc media type, linked to a Word file, set to attachment, and in the sites where this is not working, an empty file gets downloaded. So, this is not limited to PDFs. I’ve checked file permissions and media source settings, and nothing differs between the site that works and the ones that don’t. Baffling!
Do you mean you’re testing on different sites, as in separate MODX sites? Or testing the same site with different browsers?
If the former and you are talking about different sites, I would guess that the sites that are not working either 1.) don’t have the path to the PDF file set correctly, or 2.) the directory with the PDFs isn’t accessible for some reason. You can test this by taking the path you put in the Static Resource setting, and manually opening it in a browser window (domain.com/path/to/.pdf). If the PDF displays this way, I’m wrong. 
If it doesn’t display when you manually put it into a browser window, check the path again.
Yes, different MODX sites altogether. The file paths are correct, and the directories are accessible. I’ve checked all the file and folder permissions. If I paste the path in the Static Resource field into the browser, the file loads fine. If I link to that file using a regular link in the text of a page, it loads fine.
Ok, big “duh!” here. I wasn’t setting the template to “none” on the ones that weren’t working, so of course that would make it fail! They all work fine now.
I had already gotten around this by using a template that had just a script in it, with a TV called “pdf_link” in the resource:
[[!viewPDF? src=`/[[*pdf_link]]`]]
With the snippet “viewPDF” set to this:
if(!empty($src)) {
header('Location: '. $src);
}
What I like about this is that the name of the downloaded PDF is the same as the file on the server. When I use a static resource, the name of the downloaded PDF gets changed to the alias of the static resource instead. I suppose there are cases where that’s desireable. But, in this instance, the reason I’m using a static resource is for conferences that have constantly updated PDF versions of the agendas, and if I use the same name for each version, replacing the old PDF with new ones with the same file names, those PDFs get cached by CloudFlare, and so people downloading using a URL of the PDF get the old one rather than the newest one. So I need to have PDF file names change for each new version of an agenda. I imagine the same thing would happen if I use a static resource because even though the linked PDF changes, the public URL to fetch it wouldn’t change. If that URL has ‘.pdf’ on the end, Cloudflare will cache it. A question here is whether Cloudflare caches based on mime type, or by extension. I can change the extension for the PDF content type to “” or “html” so that the URL looks like a regular web page, and the PDF still loads correctly in the browser because it has the PDF mime type. But what does Cloudflare look at to determine caching?
Glad you got it sorted. I just changed that part of my comment to bold for anyone coming along this thread in the future. An empty template field is important.
Thanks for bolding that important item!
Found out from Cloudflare:
“Cloudflare only caches based on file extension and doesn’t cache by MIME type.”
So, if you want to use a static resource, and don’t want it to be cached, changing the extension in the MODX Content Type for PDFs will work, as long as you want to use the inline version. Doing that for a download version will get you a file your computer won’t recognize.