Dependent files migration (3.2 to 3.3) for HTML/XML/JATS publications

Software Support
1

Describe the issue or problem
Many images in previously published XML/JATS publications are missing from article rendering after migrating from 3.2 to 3.3 (seems limited to LensGalley plugin).

Steps to diagnose issue

  1. I see the update to LensGalley plugin, but “lensGalley/issues/68” seems only relevant for 3.4.
  2. Mostly I’d like a sanity check on the following migration that would have been applied when we updated to 3.3 in April 2025.
    // Update file name of dependent files, see: pkp/pkp-lib#6801 Capsule::table(‘submission_files’)
    ->select(‘file_id’, ‘original_file_name’)
    ->where(‘file_stage’ , ‘=’, SUBMISSION_FILE_DEPENDENT)
    ->chunkById(1000, function ($dependentFiles) {
    foreach ($dependentFiles as $dependentFile) {
    Capsule::table(‘submission_file_settings’)
    ->where(‘file_id’, ‘=’, $dependentFile->file_id)
    ->where(‘setting_name’, ‘=’, ‘name’)
    ->update([‘setting_value’ => $dependentFile->original_file_name]);
    }
    }, ‘file_id’);
    Merge pull request #6816 from Vitaliy-1/i6801_dependent_links · pkp/pkp-lib@f8380d3 · GitHub
  3. I’m assuming a partial migration took place, but it was oddly uneven. We have 2019 articles with images correctly mapped, e.g., https://scholarworks.iu.edu/journals/index.php/sdh/article/download/27720/35523/76392. And 2023 articles with failed mapping, e.g., https://scholarworks.iu.edu/journals/index.php/sdh/article/view/35527/image/Cyberspace%20Serves%20Culture_Figure1.jpg
  4. I’ve pulled and converted the relevant pre- and post-update tables (submission_files, submission_file_settings)to work on the changes externally in .csv form. (At this time it would be almost impossible to rerun the migration in place.)
  5. In theory, I understand that the intention of the migration was to support changing file “names” to “ids.” i.e., the column “original_file_name” in table “submission_files” is gone in 3.3.
  6. Whether I try to remediate the issue programmatically or manually, can you help me understand what I can do to stabilize the data other than reloading missing images one-by-one in the UI? There may not be a solution, but I appreciate your assistance in looking at the issue.

What application are you using?
OJS 3.3.0.21
Postgres 12.22
PHP 8.2.x

Thank you!

Richard Higgins
Indiana University Library

2

UPDATE: We’ve discovered a possible cause of the failed migration for this subset of images. A typesetting vendor producing JATS for us was using a file path in the image name: e.g, “name/image_001.jpg.” This naming method worked in 3.2, but it probably glitched the migration process when we updated to 3.3. We’re revising our XML and re-uploading images manually to ensure they are properly captured by the database.