File name conversion issue after the upgrade

**We were using old version of 3.1.1.2 and upgraded to 3.3.0.7 but most of the filenames have not been but have been changed successfully. We after a certain period of time come to know that issues does not shows the data because of conversion issue - Please note that site was hacked and messed badly ** My question is: what If I re run the same version upgrade again… since we cleaned the virus, would this upgrade take another run to fix the remaining file structure? or any quick work around to fix those so they start working with the latest version?

Still looking for a solution

No idea where to look at first

Application Version - e.g., OJS 3.1.2:

Additional information, such as screenshots and error log messages if applicable:

Hi @doneforyou

If the upgrade actually completed (e.g. it says 3.3.0.7 when you look at the administration area in OJS), then you can’t just run it again because OJS will assume that none of the old 3.1.1 → 3.3 code needs to run again. If the upgrade did not finish successfully you’ll probably need to restore from backup and start again.

Jason

Its showing new version in admin area and we are already stepped ahead, any manual way to look on remaining folders to make them compliant? Atleast wr cannot rollback because we have added more data to the site

@jnugent Its showing new version in admin area and we have already stepped ahead, any manual way to look on the remaining folders to make them compliant? At least we cannot rollback because we have added more data to the site, any method we can adopt manually to fix this file conversion issues?

Hi @doneforyou

Not easily, no, especially for large journals. In addition to potential name changes in the files, OJS 3.3 also has a very different files structure in the database (there is now a files table, and a submission_file_revisions table) and many things have been moved around. If that is also out of sync, doing it by hand will be quite error prone.

Regards,
Jason

@jnugent alright, but still any query to run in MySQL and at the same time on directory/files structure… something may be possible? Any nearbuy solutoin?

With the old data, I am seeing the author is not more avialable, if I am going to assign author the popup box shows error and only to those record which were messed by virus/hacking previously almost

See the recent errors, please find attached.username: admin password: [14-Sep-2021 06:15:34 America/Boise] PHP Warning: array_keys() expects parameter 1 to be array, string given in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 65 [14-Sep-2021 06:15:34 America/Boise] PHP Warning: array_shift() expects parameter 1 to be array, null given in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 66 [14-Sep-2021 06:15:34 America/Boise] PHP Warning: Illegal string offset 'en_US' in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:34 America/Boise] PHP Warning: Cannot assign an empty string to a string offset in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: array_keys() expects parameter 1 to be array, string given in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 65 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: array_shift() expects parameter 1 to be array, null given in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 66 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: array_keys() expects parameter 1 to be array, string given in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 65 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: array_shift() expects parameter 1 to be array, null given in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 66 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: array_keys() expects parameter 1 to be array, string given in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 65 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: array_shift() expects parameter 1 to be array, null given in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 66 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Illegal string offset 'en_US' in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Cannot assign an empty string to a string offset in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Illegal string offset 'en_US' in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Cannot assign an empty string to a string offset in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Illegal string offset 'en_US' in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Cannot assign an empty string to a string offset in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Illegal string offset 'en_US' in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Cannot assign an empty string to a string offset in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Illegal string offset 'en_US' in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Cannot assign an empty string to a string offset in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Illegal string offset 'en_US' in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Cannot assign an empty string to a string offset in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Illegal string offset 'en_US' in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Cannot assign an empty string to a string offset in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Illegal string offset 'en_US' in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] PHP Warning: Cannot assign an empty string to a string offset in /home2/show/public_html/show/lib/pkp/classes/core/DataObject.inc.php on line 133 [14-Sep-2021 06:15:36 America/Boise] Slim Application Error: Type: Exception Message: Could not determine the workflow stage id from submission file 958 with file stage 7 File: /home2/show/public_html/show/lib/pkp/classes/services/PKPSubmissionFileService.inc.php Line: 777 Trace: #0 /home2/show/public_html/show/lib/pkp/classes/services/PKPSubmissionFileService.inc.php(190): PKP\Services\PKPSubmissionFileService->getWorkflowStageId(Object(SubmissionFile)) #1 /home2/show/public_html/show/lib/pkp/classes/services/PKPSubmissionFileService.inc.php(224): PKP\Services\PKPSubmissionFileService->getProperties(Object(SubmissionFile), Array, Array) #2 /home2/show/public_html/show/classes/services/GalleyService.inc.php(154): PKP\Services\PKPSubmissionFileService->getFullProperties(Object(SubmissionFile), Array) #3 /home2/show/public_html/show/classes/services/GalleyService.inc.php(179): APP\Services\GalleyService->getProperties(Object(ArticleGalley), Array, Array) #4 /home2/show/public_html/show/lib/pkp/classes/services/PKPPublicationService.inc.php(208): APP\Services\GalleyService->getSummaryProperties(Object(ArticleGalley), Array) #5 [internal function]: PKP\Services\PKPPublicationService->PKP\Services\{closure}(Object(ArticleGalley)) #6 /home2/show/public_html/show/lib/pkp/classes/services/PKPPublicationService.inc.php(210): array_map(Object(Closure), Array) #7 /home2/show/public_html/show/lib/pkp/classes/services/PKPPublicationService.inc.php(235): PKP\Services\PKPPublicationService->getProperties(Object(Publication), Array, Array) #8 /home2/show/public_html/show/lib/pkp/classes/services/PKPSubmissionService.inc.php(204): PKP\Services\PKPPublicationService->getSummaryProperties(Object(Publication), Array) #9 [internal function]: PKP\Services\PKPSubmissionService->PKP\Services\{closure}(Object(Publication)) #10 /home2/show/public_html/show/lib/pkp/classes/services/PKPSubmissionService.inc.php(208): array_map(Object(Closure), Array) #11 /home2/show/public_html/show/lib/pkp/classes/services/PKPSubmissionService.inc.php(297): PKP\Services\PKPSubmissionService->getProperties(Object(Submission), Array, Array) #12 /home2/show/public_html/show/lib/pkp/api/v1/_submissions/PKPBackendSubmissionsHandler.inc.php(160): PKP\Services\PKPSubmissionService->getBackendListProperties(Object(Submission), Array) #13 [internal function]: PKPBackendSubmissionsHandler->getMany(Object(Slim\Http\Request), Object(APIResponse), Array) #14 /home2/show/public_html/show/lib/pkp/lib/vendor/slim/slim/Slim/Handlers/Strategies/RequestResponse.php(40): call_user_func(Array, Object(Slim\Http\Request), Object(APIResponse), Array) #15 /home2/show/public_html/show/lib/pkp/lib/vendor/slim/slim/Slim/Route.php(281): Slim\Handlers\Strategies\RequestResponse->__invoke(Array, Object(Slim\Http\Request), Object(APIResponse), Array)

Hi @doneforyou

It probably isn’t possible to just run some queries because the upgrade is partially complete and I don’t think you’d be able to craft queries that only affect files that didn’t migrate. Further, the upgrade process may have dropped columns or renamed tables or columns in order to reconcile the schema changes and data may no longer be in the correct place.

What I’d suggest is trying your upgrade again, with your backups, on a new installation, and comparing the files directories and database. You may be able to salvage old content that way. Further than that, I can’t really provide you with more guidance than I already have.

Best
Jason

@jnugent thanks, ok ley me try the upgrade on new domain.

When a domain name changed, what and where I have to mention it during upgrade?

Anything I have yo take care during upgrade on new domain?

The only place your domain name is mentioned is your base_url config.inc.php parameter. You can just comment it out with a semi colon.

Best,
Jason

@jnugent Thank you, here is what I have done to reproduced the same, but one question though… Is it necessary to keep the older installation ojs files while upgrading to the latest?

Ok I have went through as a fresh installation. here is what I have done

  1. downloaded the latest version
  2. just extracted that version - No previous version was on the site
  3. copy the files directory and config files back to new instalaltion
  4. setup the cache and files folder with 777 permission
  5. ran a upgrade and I am seeing plenty of these errors. however, the issue still persists

I am copying few of them as they are too many, the one orphaned submission errors I mean to say

14-Sep-2021 13:14:02 America/Chicago] WARNING: The NavigationMenu (ContextId: 1, Title: User Navigation Menu, Area: user) will be skipped because the specified area has already a NavigationMenu attached.
[14-Sep-2021 13:14:02 America/Chicago] WARNING: The NavigationMenu (ContextId: 1, Title: Primary Navigation Menu, Area: primary) will be skipped because the specified area has already a NavigationMenu attached.
[14-Sep-2021 13:14:02 America/Chicago] WARNING: The NavigationMenu (ContextId: 0, Title: User Navigation Menu, Area: user) will be skipped because the specified area has already a NavigationMenu attached.
[14-Sep-2021 13:14:02 America/Chicago] WARNING: The StaticPage “For Author” uses a path (author) that conflicts with an existing Custom Navigation Menu Item path. Skipping this StaticPage.
[14-Sep-2021 13:14:02 America/Chicago] WARNING: The StaticPage “Journal Info” uses a path (journalinfo) that conflicts with an existing Custom Navigation Menu Item path. Skipping this StaticPage.
[14-Sep-2021 13:14:04 America/Chicago] PHP Warning: Illegal string offset ‘en_US’ in /home1/show1/public_html/lib/pkp/classes/core/DataObject.inc.php on line 133
[14-Sep-2021 13:14:04 America/Chicago] PHP Warning: Cannot assign an empty string to a string offset in /home1/show1/public_html/lib/pkp/classes/core/DataObject.inc.php on line 133
[14-Sep-2021 13:14:04 America/Chicago] PHP Warning: Illegal string offset ‘en_US’ in /home1/show1/public_html/lib/pkp/classes/core/DataObject.inc.php on line 133
[14-Sep-2021 13:14:04 America/Chicago] PHP Warning: Cannot assign an empty string to a string offset in /home1/show1/public_html/lib/pkp/classes/core/DataObject.inc.php on line 133
[14-Sep-2021 13:14:04 America/Chicago] PHP Warning: Illegal string offset ‘en_US’ in /home1/show1/public_html/lib/pkp/classes/core/DataObject.inc.php on line 133
[14-Sep-2021 13:14:04 America/Chicago] PHP Warning: Cannot assign an empty string to a string offset in /home1/show1/public_html/lib/pkp/classes/core/DataObject.inc.php on line 133
[14-Sep-2021 13:14:04 America/Chicago] PHP Warning: Illegal string offset ‘en_US’ in /home1/show1/public_html/lib/pkp/classes/core/DataObject.inc.php on line 133
[14-Sep-2021 13:14:04 America/Chicago] PHP Warning: Cannot assign an empty string to a string offset in /home1/show1/public_html/lib/pkp/classes/core/DataObject.inc.php on line 133
[14-Sep-2021 13:14:04 America/Chicago] PHP Warning: Illegal string offset ‘en_US’ in /home1/show1/public_html/lib/pkp/classes/core/DataObject.inc.php on line 133
[14-Sep-2021 13:14:04 America/Chicago] PHP Warning: Cannot assign an empty string to a string offset in /home1/show1/public_html/lib/pkp/classes/core/DataObject.inc.php on line 133
[14-Sep-2021 13:14:04 America/Chicago] PHP Warning: Illegal string offset ‘en_US’ in /home1/show1/public_html/lib/pkp/classes/core/DataObject.inc.php on line 133
[14-Sep-2021 13:14:04 America/Chicago] PHP Warning: Cannot assign an empty string to a string offset in /home1/show1/public_html/lib/pkp/classes/core/DataObject.inc.php on line 133
[14-Sep-2021 13:14:07 America/Chicago] Removing orphaned submission_files entry ID 1767 with submission_id 680
[14-Sep-2021 13:14:07 America/Chicago] Removing orphaned submission_files entry ID 1768 with submission_id 680
[14-Sep-2021 13:14:08 America/Chicago] A submission file was expected but not found at journals/1/articles/1/submission/1-1-1-1-2-20181126.pdf.
[14-Sep-2021 13:14:08 America/Chicago] A submission file was expected but not found at journals/1/articles/1/submission/1-1-1-2-2-20181129.pdf.

Hi @doneforyou

Most of those are cosmetic and probably are not the cause of your upgrade issue. These, however:

Indicate that your files_dir directory is out of sync with your database, perhaps due to the virus you mentioned. OJS is telling you that there are files in your database that no longer exist on disk. There’d be no way to fix this during an upgrade, you’d need to restore those files from a much older backup. In the two that I quoted above, they are from your very first submission so are probably very old.

Jason

@jnugent make sense, thank you for your continious efforts. To achieve and step further… what we are doing now and actually ojs is doing with the users whos files are not found or missing:

  1. It does not allow users to upload news files and if we login as a user, it allow to do but change the user ID number/Sequence no.
  2. we are happy even with this and redirecting users from old location to new.

Do you think this is the quickest and best possible way to achieve the task and leaving what has happened in the past?

On the other hand… I am trying to install copernicus plugin, but for the life of me it does install and halting the plugin screen

[16-Sep-2021 00:13:17 America/Boise] PHP Warning: Declaration of CopernicusPlugin::register($category, $path) should be compatible with Plugin::register($category, $path, $mainContextId = NULL) in /home2/show/public_html/jduhs/plugins/importexport/copernicus/CopernicusPlugin.inc.php on line 48
[16-Sep-2021 00:13:17 America/Boise] PHP Warning: Declaration of CopernicusPlugin::getTemplatePath() should be compatible with Plugin::getTemplatePath($inCore = false) in /home2/show/public_html/jduhs/plugins/importexport/copernicus/CopernicusPlugin.inc.php on line 57
[16-Sep-2021 00:13:17 America/Boise] PHP Fatal error: Class CopernicusPlugin contains 2 abstract methods and must therefore be declared abstract or implement the remaining methods (ImportExportPlugin::executeCLI, ImportExportPlugin::usage) in /home2/show/public_html/jduhs/plugins/importexport/copernicus/CopernicusPlugin.inc.php on line 324

@jnugent additional… the way we are uploading missing data as I have mentioned above… we are going through the process for the uses having issues with their data and then populating the older issues with their new link/submission id/url.

Hi @doneforyou

I’m not quite sure what you mean by #1. Where is the user id changing?

As for the Copernicus plugin, I don’t think it’s compatible with OJS 3.2+ If this is the plugin you’re talking about:

Then there is code in there that will not work with 3.3

Best
Jason

@jnugent Iam referring to the number each user get, like when you see them as an admin and go to aubmiaaion section, a unique number you can see, make sense what I am referreing to? Actually ojs creats the same folder number when someone register and submit files.

Ok thanks for the plugin response, I will get in touch with the developer

@jnugent the record ID u can say

@jnugent ok I think those record ids are actually the submission id, whenever user submits new article, it assigns a new id… I think I am right here and that is the reason we are getting new numbers.

Sorry for keep you bugging…

Since you know the site was hacked and messed a lot, when I see files table I can see entries like these - for older records

/journals/1/articles/59//59–178-1-0-20131209.pdf
/journals/1/articles/206/submission/proof/206-12-2051-1-10-20190216.pdf

in first entry you can see // after 59

So, e.g. those files are in the system but they don’t appear in user account, can you tell me why?

as I know OJS has changed a lot in the file directory structure, do you think those are the malfunctioning caused by the virus and over the time and we cant fix this by anyway?

What we are doing now is try to reupload the missing data, I think that is the only solution left for us… just guide me thanks.

@jnugent Also we are using version 3.3.0.7 now, and I can see the new upgrade has already been released, anything to take care before upgrade? Please spare few minutes and put some light on my questions mentioned above, thank

So, yes, every time you create a new submission it will assign a new submission id.

To be honest I don’t know why some of your files are missing path components in the database. It’s possible they had invalid stage_id settings in your old database, and OJS uses the file stage to build the path.

I also can’t comment on your virus because I don’t know what it was or how it worked. I also think replacing your data is the way forward here.

As for OJS 3.3.0.7 to 3.3.0.8, the new version just has minor bug fixes and you can upgrade if you like. It’s a minor upgrade. 3.4 is coming out next year.

Best
Jason

@jnugent ok thanks,

Iwent ahead, used old bavkup upgraded to pitshop version :grin: and all went fine, but when I try to update to latest version, it do the same things, lots of missing info etc

One question though apart from above,

While we are in process of reloading submissions and bypassing the workflow for the older records or missing records, do you thimk it will not give us any trouble during next update? Or It will be good to go to and new data will work with futurr architecture?

Also we have main issue with our data which is prior ro version 3.1.1.2, any clue here?