in the XML file the PDFs are not imported. In the “Galleys” section of the article only the box “This galley will be available at a separate website.” is checked. The PDF should be uploaded to OJS during the import process. In OJS 2.x that was possible (Creating the XML Import File - #2 by bozana) - how to do this in OJS 3.x?
When I try to upload this XML I get an error, that a temporary file could not be created. I wonder if something’s wrong in the XML, or if some rights on our server are missing. The folder, where the remote PDF comes from, is accessible and the upload folder in ojs is writable.
I cant exactly remember why we used the internal id but think we needed the id as reference point for the DOIs that also should be generated. And i think you cannot influence this id when importing, OJS just uses the next available number. But we tried to match this number during the import.
We don’t have OJS 3.1 yet. But i can try to upgrade my personal testing system just to see if the import file still works.
The temporary file errors is concerning. We try to create a temporary file in files_dir (per your config.inc.php) as part of the import. This could be a file permissions problem, or could be an edge case not considered in relatively new code.
I’ve noticed that the XML files are imported to our upload directory. The file names are always starting with “xml…” (“xml0l1DWT”), but the error message is “Temporary file /srv/www/ojs/upload/temp/srcrGrq4y could not be created” (file name is always starting with “src”). We will also check our “NativeXmlSubmissionFileFilter.inc.php” file.
As @ctgraham noted above, please make sure that the contents of your files_dir aren’t available for direct access via the web server. This directory should either be moved outside the web root, or protected from direct access using a .htaccess file or similar mechanism.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi all, I’ve run into this exact error as well with a hosted client of ours. I’m in the middle of troubleshooting it and will report back what we find. (Clinton, I may ping you separately just to confirm our XML is indeed good.)
The issue appears to be that using <href="…"/> to pull in local files (ie. files specified on the local filesystem) doesn’t work. We were trying to do like so:
<href src="/home/journal/data/filename.pdf"/>
… which just doesn’t work. Moving the files to a web-accessible location, and referencing them that way, worked:
The 2.x version of the plugin allowed us to specify a local path, so I figure this is possibly just some missing code. If others are running into this, maybe it’s a feature worth returning?
Just want to let you know, that we have found the problem. There was a space in the URL which was not encoded (%20)
I’ve also noticed a problem with the “genre” attribute. If it’s missing or incorrect, the PDF will be uploaded, but not shown on the article frontdoor.