I recently upgraded a production site in our staging environment from 2.4.8-1 to 3.1.2.1 (Alec helped identify a duplicated index.less file, which caused a Fatal Error but after fixing that the pages seem to be looking fine, and our themer has been working to make the site look the same as the ver 2 site). Now, we are finding another issue that needs to be resolved.
The way we’ve organized the content of the site is as follows. For each article there is a summary paragraph and a link to a PDF which has the complete text (along with any images, tables, graphics, etc). After conversion, it appears that the process to display the links to the PDF’s is broken. I haven’t tested them all (there are hundreds), but I can see that the URL associated with the link has the same info (except the domain name change) between production and staging. I can see that the file structure is the same and that the config file is pointing to the correct directory (I operate with the files directory being outside the code directory). There does seem to be some sort of translation going on because the last number displayed in the URL link does not match the value assigned to the file in the article/nnn/public directory. However, the values are consistent between the two sites. When I click on the link in production I get a full page and the PDF displays in a div component id = ‘inlinePdfResizer’. When I click on the same link in our staging environment, I get a blank page (with very simple HTML of which has an emply HEAD and BODY>. Additionally, I cannot see any meaningful errors added to the error_log.
Please help.
After rereading (and correcting) my post, I suddenly had the idea that maybe I didn’t have the configuration correct for viewing PDF’s. So, I looked at the Plugin’s page and found a PDF Viewer plugin. After checking this, I am now directed to a PDF viewer, but I’m see the following error message there: PDF.js v2.0.943 (build: dc98bf76) Message: PDFDocument: steam must have data
Again, there are no meaningful errors reported in the error_log
Hi @wklyons,
Did you receive any warning messages during the upgrade? Are you sure your files_dir is correctly configured in config.inc.php?
Regards,
Alec Smecher
Public Knowledge Project Team
No warnings that I can remember. And, yes in the config file I have the line
files_dir = ../currents_files
which points to the correct location, and that directory, and all of it’s subs have 755 for permission and the pdf files are 644.
Hi @wklyons,
What sorts of filenames do you see in your files_dir? (e.g. for PDFs, .docx files, etc.)
Regards,
Alec Smecher
Public Knowledge Project Team
Hi Alec
Not sure how much detail you need, but I’ll try to give you an overview. I apologize if I go overboard (please ask more questions if you need more detail).
There are 4 directories in under the top level files directory: journals, scheduledTaskLogs, temp, usageStats (btw/ I don’t recognize the temp directory, and judging from the data stamp, it was last accessed since the conversion). Under journals is 1. Under 1 are two directories: articles and issues. Under articles are numbered directories 1-194. The last several have sub-directories of submission (and I’m guessing this must be for future issues that are in process). Directory 181 has both public and submission directories. I can find the link on the site that should open the pdf (which is named 181-838-1-PB.pdf) that is in that directory. When I download that PDF locally, it opens fine.
Hi Alec - anything new for this?
Hi @wklyons,
Ah, I think that identifies the problem. If the filenames for your submission files (e.g. PDFs) are like 181-838-1-PB.pdf, then that’s an OJS 2.x style filename. The upgrade process to OJS 3.x renames these to a different filename style. What can happen, however, is that OJS isn’t allowed to do that during the upgrade – typically due to file permissions. So when OJS 3.x tries to fetch a file, it will not be present under the expected new filename and the links will seem broken.
If OJS can’t rename a file during upgrade, it’ll generate a warning – this means you’ll typically see a ton of warning messages during upgrade about file renaming.
The best solution will be to restore your installation from backup and re-run the upgrade process, making sure that OJS has permission to rename the files.
Regards,
Alec Smecher
Public Knowledge Project Team
I’m guessing that I only need to worry about the database (i.e. restoring it from backup, then rerunning the php tools/upgrade.php upgrade step should be sufficient - of course I will turn the installed switch off first). Please confirm.
Hi @wklyons,
Yes, that should be sufficient, but do make sure you have a good backup of everything before you start.
Regards,
Alec Smecher
Public Knowledge Project Team
Ok. I was able to get the site working. But I did experience some more troubles along the way.
I just tried to do an upgrade on our staging server and I’m getting an error:
Parse error: syntax error, unexpected ‘.’, expecting ‘&’ or variable (T_VARIABLE) in …/lib/pkp/lib/vendor/illuminate/support/helpers.php on line 554
So instead, I
a) copied everything to my local environment,
b) made sure all the file permissions were correct there,
c) did the upgrade - made sure I could view the PDF’s locally (which I could)
d) copied the files directory up to the staging server (since you told me the files get changed during the upgrade)
e) restored my local databse to the staging server.
Now the staging server works fine (can view the PDFs like before).
But, now I don’t understand the file structure in my files directory. When I look in the files/journals/1/articles/nnn/public directory, it is now empty. This used to be the place where the file that would be outwardly viewing was placed. Where has this been moved to?
Thanks - wklyons
Hi @wklyons,
But, now I don’t understand the file structure in my files directory. When I look in the files/journals/1/articles/nnn/public directory, it is now empty. This used to be the place where the file that would be outwardly viewing was placed. Where has this been moved to?
Check in proof. (The upgrade process should take care of moving files as necessary.)
Regards,
Alec Smecher
Public Knowledge Project Team
Yup - it can see the final file there. Thanks for the clarification.