Me too … same problem
Did you check any of the above suggestions? Can you summarize what you tried and what the result was? What version of OJS 3 are you using, and what version did you upgrade from?
Public Knowledge Project Team
Hey @asmecher, just to update you.
Sended the files to you yesterday.
Upgraded from 2.x to 3.0.1 and the problem persists
As I can see, in my case, the files are not finded in the upgraded version.
What should the permissions be? Thanks
My ojs3.0.1 has the same issue as the screenshot attached in previous post:
PDF.js v1.0.907 (build: e9072ac) Message: stream must have data
Has anyone found a solution yet?
My files_dir path and file permissions are correct.
I have also tried moving files directory outside of the web root and updated config file based on that which didn’t help.
This is the error I get in my browser’s console page:
Uncaught TypeError: Cannot read property 'firstElementChild' of null at PDFViewer (viewer.js:3918) at Object.pdfViewInitialize [as initialize] (viewer.js:4619) at HTMLDocument.webViewerLoad (viewer.js:6179)
When I disable PDF Viewer plugin, I only get a blank page when trying to open a pdf.
See also this cross posting. (It’s generally best not to post the same problem in two places – it makes the forum hard to keep organized.)
Public Knowledge Project Team
@dalmasont, I tried your upgrade today as follows:
Unpacked the OJS 2.4.x files into the files directory
Loaded the OJS 2.4.x database dump into a new database
Checked the version information is as expected using…
php tools/upgrade.php check
Ran the upgrade using…
php tools/upgrade.php upgrade
This gave me numerous warnings like…
PHP Notice: unserialize(): Error at offset 55 of 753 bytes in /home/asmecher/git/ojs/lib/pkp/classes/db/DAO.inc.php on line 347
…but these are due to character encoding mismatches between my setup and yours (Latin1 vs. UTF-8) and can be ignored.
The upgrade appears to have worked fine and I’m able to download PDFs. Enabling the PDF.js plugin, I’m able to view them in a built-in viewer.
My suspicion is that the file permissions within your files directory are not sufficient to allow OJS to rearrange its contents. Note that numeric permissions (read/write/execute) are not enough – you’ll also have to consider the file’s ownership. This FAQ entry has details.
Note that the command-line upgrade tool will probably be running under your account, so its needs for file permissions may be different than those of your web server. It’ll pay off here to know what your system expects, rather than trying different permission levels to see what works.
Public Knowledge Project Team
Thanks for the help.
I’ll talk to the server admin to try to work with the permissions.
Talked to the system admin and he readed all we have in this tread. He also readed the FAQ entry and changed the permissions as informed.
Unfortunately, that did not resolved the issue…
As a last try, I copied the files dir, the database and installed in another server (a hostgator one…)
Tried to upgrade and the problem persists.
The debug message is as follows:
[24-Jan-2017 19:34:43 America/Chicago] PHP Warning: Cannot use a scalar value as an array in /home/proje439/public_html/revista/lib/pkp/classes/core/DataObject.inc.php on line 133 [24-Jan-2017 23:34:43 America/Sao_Paulo] PHP Strict Standards: Declaration of FileApiHandler::authorize() should be compatible with PKPHandler::authorize($request, &$args, $roleAssignments, $enforceRestrictedSite = true) in /home/proje439/public_html/revista/lib/pkp/controllers/api/file/FileApiHandler.inc.php on line 25 [24-Jan-2017 23:34:43 America/Sao_Paulo] PHP Strict Standards: Declaration of SubmissionFileDAO::fromRow() should be compatible with PKPSubmissionFileDAO::fromRow($row, $fileImplementation) in /home/proje439/public_html/revista/classes/article/SubmissionFileDAO.inc.php on line 23 [24-Jan-2017 23:34:43 America/Sao_Paulo] FileApiHandler: File /home/proje439/public_html/revista/PAJMT//journals/1//articles/35/submission/35-1-92-1-2-20151216.docx does not exist or is not readable! [24-Jan-2017 23:34:43 America/Sao_Paulo] ojs2: 500 Internal Server Error
I realy don´t know what to do now.
Planning to do a fresh install of the 3.0.1 version and mannually inserts all the papers already published.
Thanks for all the help!!!
I would suggest looking around your log files for something that provides more detail about that 500 Internal Server Error. You may have a different Apache error log from your PHP error log.
Public Knowledge Project Team
The error 500 is because the file wasn’t finded. That’s what the server admin says.
There where 37 articles in the journal. I manually update each one and now the pdf can be loaded.
Probably ther is some apache misconfiguration, but for me, the manual update was enough.
Once more, thank you for all the help!!!
I have similar issues. PDFs not loading.
I have upgraded OJS 2.4.6 to 3.0.2 on Linux (complete package with duplicated database and files).
PHP version - 5.6.30
Apache version - Apache/2.4.23
Database driver - mysql
Database server version - 5.6.35-cll-lve
I have double checked the file path, its correct, and so are the file permissions I believe.
Any help would be appreciated.
Is it OK to cup-paste the error log here?
The update to OJS 3 reorganizes the files in the
file_dir. Was your upgrade without any warnings? Have you checked the access permissions in your
file_dir and that the actual PDF file is there and in the correct subfolder?
Else, yes, if there are any errors in your PHP error log file, when viewing the PDF, you can post them here – you can remove the sensible information (e.g. IP a addresses) before copying them here…
Hi, thanks for the reply.
There were warnings…
Strict Standards: Declaration of DevelopedByBlockPlugin::getSeq() should be compatible with BlockPlugin::getSeq($contextId = NULL) in root/public_html/170729johr/plugins/blocks/developedBy/DevelopedByBlockPlugin.inc.php on line 79
Strict Standards: Declaration of DevelopedByBlockPlugin::getBlockContext() should be compatible with BlockPlugin::getBlockContext($contextId = NULL) in root/public_html/170729johr/plugins/blocks/developedBy/DevelopedByBlockPlugin.inc.php on line 79
Strict Standards: Declaration of DevelopedByBlockPlugin::getEnabled() should be compatible with BlockPlugin::getEnabled($contextId = NULL) in root/public_html/170729johr/plugins/blocks/developedBy/DevelopedByBlockPlugin.inc.php on line 79
Deprecated: Non-static method Application::getName() should not be called statically, assuming $this from incompatible context in root/public_html/170729johr/lib/pkp/classes/install/form/InstallForm.inc.php on line 146
Deprecated: Non-static method Application::getName() should not be called statically, assuming $this from incompatible context in root/public_html/170729johr/lib/pkp/classes/install/form/InstallForm.inc.php on line 148
Deprecated: Non-static method Application::getName() should not be called statically, assuming $this from incompatible context in root/public_html/170729johr/lib/pkp/classes/install/form/InstallForm.inc.php on line 150
Deprecated: Non-static method VersionCheck::getCurrentCodeVersion() should not be called statically, assuming $this from incompatible context in root/public_html/170729johr/lib/pkp/classes/install/form/MaintenanceForm.inc.php on line 37
Strict Standards: Non-static method Version::fromString() should not be called statically in root/public_html/170729johr/lib/pkp/classes/site/VersionCheck.inc.php on line 115
Deprecated: Non-static method PKPRequest::getUserVar() should not be called statically, assuming $this from incompatible context in root/public_html/170729johr/lib/pkp/classes/form/Form.inc.php on line 351
Deprecated: Non-static method PKPRequest::_checkThis() should not be called statically, assuming $this from incompatible context in root/public_html/170729johr/lib/pkp/classes/core/PKPRequest.inc.php on line 582
Sharing the PHP error log file…
Thanks in advance.
It seems like the upgrade did not work well – there were some warnings: “Unable to find a match for…” and “copy… failed to open stream”. This means that those files in the OJS
files_dir could not be found and reorganized by the upgrade script. Could you double check you OJS 2.4.x installation and
files_dir, if these files are there and eventually correct them (best via the GUI)? Also please double check the permissions for the
Once you have fixed the files and permissions, you should do the upgrade anew, on the fixed OJS 2.4.x backup data + files.
I installed afresh.
The pdfs are loading now. Thanks. And I have no clew what went right
I still got those errors while upgrading. Anything that I should look into.
If you still had the errors I mentioned in the post above, you should take care of them and check what is wrong with those files in OJS 2.4.x. The other errors/warnings, like strict standard and deprecation, are not important.
I am upgrading OJS 2.4.6 to 3.0.2 now.
I am having the same errors when opening PDF view of articles.
Stack Trace: File: (unknown) line (unknown) Function: FileApiHandler->downloadFile(Array(4), Object(Request)) File: //lib/pkp/classes/core/PKPRouter.inc.php line 372 Function: call_user_func(Array(2), Array(4), Object(Request)) File: //lib/pkp/classes/core/PKPComponentRouter.inc.php line 262 Function: PKPRouter->_authorizeInitializeAndCallRequest(Array(2), Object(Request), Array(4)) File: //lib/pkp/classes/core/Dispatcher.inc.php line 134 Function: PKPComponentRouter->route(Object(Request)) File: //lib/pkp/classes/core/PKPApplication.inc.php line 227 Function: Dispatcher->dispatch(Object(Request)) File: //index.php line 68 Function: PKPApplication->execute()
Recently I found that files_dir path was wrong in the config file during the upgrade.
Journal manager was unable to login with existing login credentials and some images were missing after upgrade.
Is there a way to fix these issues or I have to do a fresh upgrade again?
If the files_dir path was wrong during the upgrade you will have to do the upgrade again – the upgrade makes some restructuring of the files there, important for OJS 3.x to work properly…