Eric Mann

Interesting …

The issue is actually in the underlying structure of PHP. I’m implementing ArrayAccess for WP_Session which is what gives you the array-like structure of the parent container. Unfortunately, ArrayAccess doesn’t play well with multidimensional arrays.

For whatever reason, the original PHP authors chose to make ArrayAccess return properties in read mode (not by reference). So when you call $wp_session['colors'] it returns a read-only version of the array. Adding to the array will have no effect.

A workaround, until I figure out a more permanent solution, would be to:

$wp_session = WP_Session::get_instance();

$colors = array();
$colors[] = 'daa';
$wp_session['colors'] = $colors;

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 http://yoursite.com/publications.

Each publication will have its own link (i.e. http://yoursite.com/publication/whatever-title-you-chose) 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: https://github.com/ericmann/WP-Publication-Archive/issues

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.

Authors work like tags in the current version. So when you start typing an author’s name, WordPress will make a suggestion of which author to include.