I’m testing the upgrade from the very old to the very new OJS. Since we need the supplementary files to be shown on the pages with the articles, following the advice given here, my upgrade sequence was 2.4.8-1 => 3.1.2-4 => 3.3.0-21 => 3.5.0-1.
Before the upgrade, the supplementary files were accessible through the reading tools block plugin via links such as https://journal.tld/rt/suppFiles/1234 (for the page with all of them) or https://journal.tld/article/downloadSuppFile/1234/2016 (for downloading the particular file). After the upgrade, the link to the same supplementary file became https://journal.tld/article/view/1234/6303
So I can’t now find a 1:1 correspondence between the old and the new URLs, can I? This is relevant because some time ago our editors have started to put the links to the supplementary files into the PDF galleys. As the URLs are quite different, after upgrade, we will be left with a bunch of broken URLs and no way of quickly hacking this via the web server redirects.
Am I right to assume that we’re screwed, ‘cause the URLs will have to be repaired manually by going to the article pages, finding the corresponding supplementary files, taking their URLs, and recreating and reuploading the PDF galleys with the right URLs?
Do you still have a backup of the database? If yes, then it’s possible to at least automate the permanent redirects and also update the texts/links in the database.
Hi @jonasraoni ! Thank you for the feedback! Sadly, we’re still in the early phases of planning our upgrade. There’s so much to take into account, after all this time… our primary installation is a multi-journal one, and even configuring the web server properly is a huge pain. Not in the least because of things such as this and this - regarding the latter, I nearly thought I’ve solved the problem of apache config for both restful and restless URLs, but my configs result in cyclic redirects with the new routing for multiple languages in OJS 3.5 .
I’m starting to appreciate the “one journal - one OJS - one vhost” approach, although with 10+ journals this will require considerable maintenance overhead.
So, returning to this topic - we have the original database. I’d appreciate any hints as to where to look for the published supplementary files (at least in the 3.5) because I know little about the OJS database model. To me, this task seems to require aggregating data from multiple tables…
I think few people here are familiar with the OJS 2 structure, I guess you’ll probably have to run a query to extract a bunch of IDs on the old database, then another one on the new database, to match the IDs.
It might be smart to keep the OJS 2 backup around for some time, as well as the HTTP access log (to inspect the 404 hits and understand if you’ll need more redirects)
I’m sure this is doable, but it will require too much efforts from my side (setting up an OJS 2 with supplementary files > running an upgrade > inspect both databases > plan > write queries), so I can’t help for now.
I’ll take a look at the other topics that you’ve mentioned, as they are more relevant to the application.
Hi @jonasraoni and @voffch! I’ve just added SchemaSpy documentation for OJS, OMP, and OPS to the pkp-docs repository. This is just a git commit to our repo, though, and you won’t see the results show up live on the dev documentation until the documentation hub gets rebuilt.
Regards,
Alec Smecher
Public Knowledge Project Team
.