Support » Plugin: WP Publication Archive » pdf's not readable on download

Viewing 5 replies - 1 through 5 (of 5 total)
  • Plugin Author Eric Mann



    Looking at your site, there’s something going wrong with the download. The file that is downloading is not the PDF but is instead an HTML file containing an error:

    Directory has no index file.

    For some reason, an include somewhere either isn’t working or your server (I see you’re running Nginx) is configured in such a way that streaming the PDF file to the browser through openfile.php is disabled.



    So I am over my head in all this, but still in the fight. A copy of the download link looks like this:|

    If you cut it down to just the file location ( it opens the pdf in the browser.

    Here’s a cut and paste of the openfile.php, in case anything jumps out at you.

    if ( ! isset($_GET[‘file’]) )

    if ( strpos( $_GET[‘file’], (isset($_SERVER[‘HTTPS’]) ? ‘https|’ : ‘http|’) . $_SERVER[‘SERVER_NAME’] ) === false )

    $mime = new mimetype();

    $fPath = str_replace(‘http|’, ‘http://’, $_GET[‘file’]);
    $fPath = str_replace(‘https|’, ‘https://’, $fPath);
    $fType = $mime->getType( $fPath );
    $fName = basename($fPath);

    $origname = preg_replace(‘/_#_#\d*/’,”,$fName);

    $fContent = fetch_content( $fPath );

    output_content( $fContent, $origname );

    function fetch_content( $url ) {
    $ch = curl_init();
    curl_setopt( $ch, CURLOPT_URL, $url );
    curl_setopt( $ch, CURLOPT_HEADER, 0 );


    curl_exec( $ch );
    curl_close( $ch );

    $fContent = ob_get_contents();


    return $fContent;

    function output_content( $content, $name ) {
    header( “Expires: Wed, 9 Nov 1983 05:00:00 GMT” );
    header( “Last-Modified: ” . gmdate(“D, d M Y H:i:s”) . ” GMT” );
    header( “Content-Disposition: attachment; filename=” . $name );
    header( “Content-type: application/octet-stream” );
    header( “Content-Transfer-Encoding: binary” );

    echo $content;

    Thanks for getting back to me!

    Plugin Author Eric Mann


    Yeah, I know what openfile.php looks like. My only guess, without seeing how your server is configured, is that your server is choking on the fetch_content() call. This is using cURL behind the scenes, which can sometimes be disabled or hobbled by the server configuration.

    Is there any chance you can check your error logs to see if anything is being reported there?

    But the Nginx error that you’re seeing is a common error. If you try to access a directory without specifying a filename, Nginx will look at whatever’s defined in the try_files declaration for the server config. Usually this includes index.htm index.html index.php. So some file, somewhere, is trying to read or access a directory without specifying a filename and that directory is lacking one of these three files.

    My guess is that the $_GET variable is being stripped off, so openfile.php is trying to do a cURL call for the directory where it resides (basically doing a cURL GET of ''). But I can’t be sure of this without seeing your error logs.

    Ideally, the logs will show exactly what’s being requested, by what, and what error is occuring. If you can copy-paste those logs, we should be able to narrow things down.

    Thanks for the reply’s Eric!

    Talked to the server people and they found no problems. No log errors were showing up for pdf downloads.

    Talked to the web design company and they went through and found this:

    “It looks like when the caching plugin (super cache) updated, it broke the JavaScript files concatenation. I removed that caching plugin and added a new one that’s less aggressive (quick cache). I also added a rule that prohibits the scripts concatenating, which can break them and cause things that depend on AJAX to break.”

    They changed the site so that pdf’s are hyper-linked in the wp page editor to open in a new tab, not as slick as wp pub archive but gets the job done.


    Plugin Author Eric Mann


    Hmm … well, the new version of the plugin (hopefully done before the end of the year) will be dumping the openfile.php method to load files anyway. It’s old, slow, and as you’ve demonstrated, prone to failure for a variety of reasons.

    The new system will allow you to treat each publication as a post – with its own description and meta information. You can still use the shortcode to list archives, or can allow people to navigate through a deeper archive at

    Each publication will have its own link (i.e. which will display document details, meta information, and present both view and download links. The download link will force the file to be downloaded (as before). The view link will dynamically stream the resource to the browser, allowing the browser to take over and do whatever it needs to the file – i.e. display on screen, continue as a download, or whatever is the default behavior for that file type.

    If there’s anything else you’d like to queue up as a change, feel free to add an issue to my internal roadmap and I’ll see what I can do:

Viewing 5 replies - 1 through 5 (of 5 total)
  • The topic ‘pdf's not readable on download’ is closed to new replies.