Testing an upgrade from 2.4 to 3.1 - duplicated everything but the files directory (copied the wrong one). So, I broke the current version (the upgrade went fine but the journal admins haven’t tested yet) - the PDF/HTML won’t load for the articles (http://cms.arizona.edu/). Is there a way to change the code in 2.4 so it can find the files or is there a rename file script to restore the 2.4 file conventions?
Cheers,
Bart
Please make sure that path to pdf files in config.inc.php is correct.
It is - that is not the issue - the upgrade script renamed all the files in my v2 files directory because I was looking at the wrong folder - I need to revert those file name changes, if possible.
Can you repeat upgrade with correct folder?
You are not understanding what I have written, but I thank you for trying.
I am fairly sure that there is no script that will change the file names back to 2.4 compatibility. Not only are the files renamed, but they are also moved around.
Are you sure that your service provider is not doing automatic backups from the file system? Maybe you could get an old copy of the folder from them?
Dear @Bart_Rossmann,
@vvucic is correct in the sense he advises you to do an upgrade from your backup which you should have saved before the upgrade process.
Thanks All,
I can pull a restore for that folder, but it is a poorly supported service at a University, so the time delay was the issue. A restore may take 3-4 days, so I will put in the request and still pursue a faster resolution.
The migrateFiles function in the upgrade.inc.php uses locations written to article_files_migration in the db (a temporary table) - does anyone know if the db entries created the upgrade process construct the v2 file paths from other database entries or from actual files paths?
Cheers,
Bart
Hi @Bart_Rossmann,
Restoring from a backup is definitely your best approach. The files migration is not designed to be reversible.
If it would be any help, I can provide links to the areas in OJS code where the file paths and names are constructed in both 2.x and 3.x, but you can expect some awkward scripting in order to use them.
Regards,
Alec Smecher
Public Knowledge Project Team
Thanks Alec,
That would be very helpful - I have the v3 information I need already - so just the v2 constructs are needed. I have the v2 database still, so I’ve been outputting from some SQL queries, but my matches are not close enough 
Cheers,
Bart
And…I think I found everything I need and was able to revert all the file changes.
Cheers,
Bart
Hi Alec, are the tables whose name ends in “_migration” (article_migration, article_files_migration, …) only created and used during the upgrade from OJS 2 to OJS 3? Once the upgrade completes successfully, should those tables not be present in the database? In other words, if those tables (article_migration, etc.) are still present and have data after the upgrade, does it mean that something was wrong during the upgrade?
Hi @santsho,
Yes, those are created during the OJS 2.x to 3.x upgrade process, and should be deleted upon completion of the upgrade. If they’re lying around afterwards it suggests that the migration didn’t complete successfully.
Regards,
Alec Smecher
Public Knowledge Project Team