Hi, we just upgraded two OJS from 3.1.0-1 to OJS 3.1.1 and all the image files that had been uploaded as “other” files by authors have gone missing. They’re on the server but OJS is not showing any image files now.
There is no file category that easily fits image files so we tell authors to use the “other” file category when uploading docx files and hi-res photos.
We have had to revert back to our backup of OJS. This appears to be a major bug that needs to be fixed urgently.
Also, OJS 3.1.1 does not include the capability for authors to edit metadata prior to copyedit is finished - we need this urgently - we have discussed this previously, this is a major problem for us.
Hi, we just upgraded two OJS from 3.1.0-1 to OJS 3.1.1 and all the image files that had been uploaded as “other” files by authors have gone missing. They’re on the server but OJS is not showing any image files now.
Do they show up in the lists (“grids” in OJS terminology) but not in your published articles, or do they not show up in the lists anymore at all? A few screenshots to clarify where they are and aren’t might help.
Also, OJS 3.1.1 does not include the capability for authors to edit metadata prior to copyedit is finished - we need this urgently - we have discussed this previously, this is a major problem for us.
I think you’re talking about this thread. There are some good ideas there for how to proceed, but they haven’t been implemented yet.
Regards,
Alec Smecher
Public Knowledge Project Team
Hi Alec, the image files were missing from every paper, including those in the submission queue.
For all papers all that was left were the article type and the galley type (for those papers that were published)
We were forced to back out to our backup as this is essentially a show stopper for us. We cannot lose the image files in OJS.
Hi Alec, thx for the info about the metadata edit change, we would like to vote for an increase in the priority for this code update. It is most important for us to be able to get authors to fix the metadata.
Hi Alec, is there any news about this bug fix? We cannot move to OJS 3.1.1 until it is fixed.
there was no obvious way for authors to upload hi-res image files so we asked them to use the “other” file type. We need to image files to be carried over when we upgrade to OJS 3.1.1.
Also, what file type should authors use to upload images. We get them to use “Article” to upload docx files of their work.
Was any of your content upgraded from OJS 2.x to OJS 3.x? If not, then the quickest work-around for the moment is to remove/comment out the following line in dbscripts/xml/upgrade.xml:
<code function="repairSuppFilesFilestage" />
Then run the upgrade script as part of the normal upgrade process.
Regards,
Alec Smecher
Public Knowledge Project Team
EDIT 1: but I think removing that function is the correct solution for you...
s. also the discussion in this GitHub Issue: https://github.com/pkp/pkp-lib/issues/3016
There was a bug when migrating supplementary files from OJS 2.4.x to OJS 3.x – they were not migrated as galleys but as submission files. Then I “repaired” that, but I could not differentiate between the new submissions files uploaded in a category that is defined as supplementary
Thus, maybe I will change all that, so that those files are in both places i.e. that there are twice there, as submissions and galleys files. @asmecher, what do you think?
Hmmm…
EDIT: or maybe not to try to repair them at all for those coming from 3.x? If then someone is missing his/her supp files published, he/she can still apply that function? – it seems to be more the case that the files are correctly in submisison files grid than the other way around…
hmmm… – else we would heard more from the other cases earlier…
thank you @bozana for the pointer. Unfortunately, I’m away until early May and only getting to do email sporadically. I understand that a cpanel testbed has been setup with my journal which is OJS 3.1.0-1 so that we can load OJS 3.1.1 and then debug to find out what happened to the images, but I’m not going to be able to do this until I return home in early May. I understand the files are still in the folders, but not visible in OJS.
@MarkAGregory, for when you get back to your desk, I think the Coles-notes version for you will probably be this suggestion, since your content is already in OJS 3.x and you’re happy with the way it’s presenting there.
@bozana, I would lean towards reverting the original fix, so that supplementary content migrated from OJS 2.x to OJS 3.x is left as unpublished submission files. Some journals have been caught by surprise that supplementary content gets migrated to galleys, probably not understanding that the content was published in their 2.x installation (though better hidden) anyway. Duplicating the content is guaranteed to make everyone at least a little bit unhappy.
I think content that’s already in OJS 3.x is adversely affected by the current script, so removing that will also resolve the issue for OJS 3.x to OJS 3.x upgrades.
Regards,
Alec Smecher
Public Knowledge Project Team
We applied the script on a sandbox version of our site after updating to 3.1.1 and we still have problems with “untitled” being added to galleys and missing images in the review and copyedit
Hmmm… and I am wondering why those “Untitled” is being added That article in the screenshot had only one galley (that PDF galley)? Or something else too?
Thanks a lot!
Bozana
p.s.
We are releasing the 3.1.1-1 this week, that fixes that repairSuppFilesFilestage function…
Also just to be sure: always use the clean full backup of the old version before starting a new upgrade round…
Hi @bozana, the hosting provider made the changes based on your earlier post. I’m manually trying to fix our OJS - it is a lot of work and I do hope that more testing can occur before updates are released.
Yes we updated from 3.1.0-1 to 3.1.1.1
We went from 2.8.4 to 3.1 then to 3.1.0-1
There is one PDF in the galley and the “untitled” appear to be the image files that were uploaded as “other” in OJS 3 or supplementary files in OJS 2.8.4
We also lost all production docx files and there is an option to upload files but no “select file” - pity
I have had to restore these files into OJS from a file based backup that I keep.
Also many papers lost the copyedit files but you can select these using the button.
Confidence on whether or not the files are the correct ones is quite low now.
Thankfully, we’re not a large journal otherwise this would have been a terminal problem.
If you have a new update - please add the ability for authors to edit metadata as discussed in another thread - we need this desperately. We have enough work trying to fix our file system now.
What does this mean - “Also just to be sure: always use the clean full backup of the old version before starting a new upgrade round…”
We’re not programmers and have no idea how to backout repairs made to the code to fix the bugs. We’re now struggling to stay afloat with OJS and have to check everything weekly to ensure that we do not have more problems.
We need to get one update to work without OJS falling over and then we can settle out site down.
Just to understand: What are your steps now? Did you update your production system to 3.1.1? Or just test system?
I thought you have reverted your production system and are testing the upgrade again, on a test system. Thus, I thought, you could either remove that function from the upgrade script and test it again or wait for the next release and test it again.
Hmmm…
What does this mean - “Also just to be sure: always use the clean full backup of the old version before starting a new upgrade round…”
I mean: I assumed your production system is OK i.e. reverted. If you are now testing an upgrade and that upgrade does not work and a function needs a fix, then always start again with the clean original data (e.g. from the production system) for a new upgrade test.
we have updated to 3.1.1 now, as we do not want to fall behind. We have applied the script that you provided earlier in this thread (so please take it into account with the update) and have worked to fix the missing files manually. We’ve also been deleting the extra galley files and uploading the image files again as “other” in the copyedit section. It is taking hours.
Yes, we need the metadata fix please. If you cannot find the thread with the suggested approach, please ask and I’ll provide a link. I’m happy for any approach that lets authors fix metadata up to and during copyedit - but not when the production stage is commenced.
Sorry @MarkAGregory for the bug and that it cased you so much work!
Could you please send me what do you see when you execute this SQL: SELECT file_id, revision, submission_id, file_stage, assoc_id, assoc_type FROM submission_files
Just to see if everything seems OK now for the next release… – It should be all fine now, I think – with that script, all your “other” files were copied to the submission files grid… and when you upload them to the other, right places in the workflow (unfortunately) manually it should be OK… but just to double check…
THANKS!!!
Bozana
That article in the screenshot had only one galley (that PDF galley)? Or something else too?