Support ⇒ Troubleshootings ⇒ IE and PDF Downloads ⇒ Community Forums ⇒ CPG Dragonfly™ CMS
Forum IndexTroubleshootings

IE and PDF Downloads Reply to topic


So I'm hitting this odd issue the last year or so with members having issues with PDFs not working.

I must have been drinking stupid juice as I never bothered to ask about what browser they were using.

Today I went poking around a site because a member that is smart enough to know how to work the downloads and that has done so successfully for yearswas reporting an issue.

FF and Chrome handled it fine. PDF is downloaded and opens fine. But in IE I get this error saying:

Adobe Acrobat DC could not open 'nameoffile.pdf' because is is either not a supported file type or because it has been damaged (for example, it was sent as a email attachment and wasn't correctly decoded).

To create an Adobe PDF document, go to the source application. The print the document to Adobe PDF.


So part of says oh this is an Adobe issue but then my head says well, then why do the other two browsers handle it fine? Then I say well it's because IE sucks and I can't help that but of course that isn't a satisfactory response/resolution since sooo many people prefer that browser still for some unknown reason.

Then it occurs to be that maybe it might be something that the Downloads Pro module is maybe doing that isn't compatible with IE in terms of how it interprets the download it's being asked to download or open?

Or maybe *I* am saving the PDF wrong. I am not sure what is happening and am trying to determine what the culprit is so I can figure which area I need to address.

Has anyone else run across this? Or have any idea what is going on with it? I'll be trying to investigate this from the IE and Adobe aspects as well, but it just seemed odd so figured it couldn't hurt to ask here.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]


Okay ...

Just had my other half run through some things with me on his computer. These were the checks that I did.

He had trouble with Chrome and IE at first.

So I wanted to determine if it was a PDF thing or a Downloads Pro module issue.

I uploaded a copy of the file to the root directory (i.e.: domainname.com/filename.pdf). I then tried to access and save and open the PDF directly from that link. I had NO trouble at all with it on any browser.

Other half tried, and it worked perfectly for him on all browsers.

So then I moved that verified working file for the root directory to root/uploads/downloads directory, moved out the old download file, and then renamed the working file that I moved into the directory the same as the one that I had moved out.

Cleared the site's caches.

Cleared our browser caches.

IE still gives the same error to the same exact file that it opened without ANY issue seconds ago. Chrome and FF handle it fine. Other half had same result.

As I type this out wondering if it is a permissions issue, but then why would it work for FF? I'm stumped but I feel this is showing me that there is an issue with the module and not so much the pdf file since it works effortlessly outside the Downloads module structure.

Any ideas??? I'd hate to kick that module to the curb!

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]


Oh, yeah ... the server specs for the server that this particular install is on are the following:

(Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.5.52 / PHP 5.4 / 9.4.0.0 ]

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]


Okay - so this is interesting. I took the same exact file that I uploaded through Downloads Pro and manually put it into the root/uploads/downloads/ directory. I then went to the Downloads Pro module and added that file as a mirror using the url to the file that I added to the root/uploads/downloads/ directory.

THAT version of the same file is working perfectly. Not sure what might be going on with this. It's quite odd.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]


If the files are 100% byte compatible, then probably support.microsoft.com/kb/293792
v10 handles that issue partially, but v9 totally not.

Try in v9 /includes/cmsinit.inc at the top somewhere:
if ('contype' === $_SERVER['HTTP_USER_AGENT']) { header('Content-Type: application/pdf'); }

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
Fedora 25 / Apache 2.4.27 / MariaDB 10.1.26 / PHP 7.1.10 / Mercurial

Last edited by DJ Maze on Fri Jan 06, 2017 8:58 am; edited 1 time in total


Thank you - is V10 now considered the stable version?

Just wondering if I should start upgrading the 9.4 ones.

Server specs (Server OS / Apache / MySQL / PHP / DragonflyCMS):
[ Linux / Apache 2.2.8 / MySQL 5.0.45 / PHP 5.2.6 / CPG 8.2b - 9.3.4.1]

All times are UTC


Jump to: