OJS 3.3: is there a mechanism for batch replacement/versioning of galley files in OJS?

One of the journals I support just had a massive number of articles (20 years’ worth, or an est. 700 articles) from their back file re-scanned and would like to replace the existing article galleys or for batch versioning, uploading, and publishing. I’ve been investigating options for doing this in batch via Import and Export. The manual process would take a ridiculous amount of time and introduce a lot of opportunity for human error.

The Native XML tool seems to only be viable for net new submissions instead of versions or file replacement.

The REST API seems like it would be the best bet for this - it can create new versions and publish submissions - but I’m unable to determine how to connect a new submission file to editable new version of a publication.

Is there a pathway for this kind of bulk replacement/versioning, whether through the API or by, I don’t know, getting my IT support to replace the database files? If not now, is this likely to be possible in OJS 3.4?

Currently using OJS 3.3.0.14.

Thanks in advance.

Hi,

I just wrote this: GitHub - ajnyga/galley

Note that it is for 3.2 but probably it would be just a few changes to get it to work with 3.3.

Check the readme for details: galley/README.md at master · ajnyga/galley · GitHub

NOTE! This is for now a bit experimental, I have only imported files for a single journal and they are actually right now checking if everything went ok.

Edit: so I recommend that if you use this, make a backup and do some testing…

3 Likes

@ajnyga fantastic, thanks so much for suggesting this! This is definitely the most promising option so far. I’ll work with my IT support on getting it to work.

Our use case was that we import a lot of archives using GitHub - ajnyga/tsvConverter: Excel to OJS3 XML conversion tool

The problem in some cases is that the journals do not always have the permission to publish the articles in digital form and have to ask the permission again and that of course takes time to contact the authors. So some journals have imported just the article metadata in some cases.

We are then in a situation where I only know the article title, the issue where it is published and the file they want to add to an article already in the archive. So my galley plugin serves this purpose.

If I would know for example the publication id the article has in the OJS database, the plugin would be a lot simpler.

Also note that my plugin first checks if the article already has a galley and does not try to add a new one. So in your case you need to think what to do with the old galleys first. Of course one option would be that you rewrite the code so that it creates a new version first, adds the galley there and the publishes the new version, like you envisioned.

It is a good idea to let the it people to check the code first. I originally wrote this for internal use but great if you can use it to solve you problem. You are of course welcome to fork it and create you own version.

1 Like

Hi @tmrozewski,

Alternately, you could try working with the files directly on the filesystem, since it sounds like you’re just replacing existing files. In OJS 3.3.0, you can find out the filesystem location for each file with a query like the following:

SELECT f.path, g.galley_id AS galley_id, g.publication_id AS publication_id, p.submission_id AS submission_id
FROM files f
JOIN submission_files sf ON (f.file_id = sf.file_id)
JOIN publication_galleys g ON (g.submission_file_id = sf.submission_file_id)
JOIN publications p ON (g.publication_id = p.publication_id);

Of course, take a complete backup before working with either the database or the filesystem directly!

Regards,
Alec Smecher
Public Knowledge Project Team

1 Like

Thanks @asmecher - I’ll bring that solution to my team as well.
https://forum.pkp.sfu.ca/t/ojs-3-3-is-there-a-mechanism-for-batch-replacement-versioning-of-galley-files-in-ojs/77596
forum.pkp.sfu.ca
CC-MAIN-2023-23
29411
application/http; msgtype=response
sha1:UJTPREGR4OXO2RGPUF5D347DJMCPS6TJ
<urn:uuid:8e19e15d-fd84-4f9a-8a91-87693e2ae4c7>
2023-06-04T06:39:39Z
142.58.229.37
text/html
sha1:CPYZNH7CFBM3ATSWXCWLV4OWZH2SNDUH
<urn:uuid:868fba8c-e01a-4bcd-bac7-09bbd8f19e9c>
https://forum.pkp.sfu.ca/t/ojs-3-3-is-there-a-mechanism-for-batch-replacement-versioning-of-galley-files-in-ojs/77596
response
<urn:uuid:fd161455-db35-4bac-8002-c22dc6b4eb48>
isPartOf: CC-MAIN-2023-23
publisher: Common Crawl
description: Wide crawl of the web for May/June 2023
operator: Common Crawl Admin (info@commoncrawl.org)
hostname: ip-10-67-67-239
software: Apache Nutch 1.19 (modified, https://github.com/commoncrawl/nutch/)
robots: checked via crawler-commons 1.4-SNAPSHOT (https://github.com/crawler-commons/crawler-commons)
format: WARC File Format 1.1
conformsTo: https://iipc.github.io/warc-specifications/specifications/warc-format/warc-1.1/