If you are 100% certain that there was no previous upgrade attempt, then I guess you could try just deleting (or renaming) the ‘article_galleys_stats_migration’ table.
However, I find it hard to believe that the table would exist there because of any other reason. Unless the upgrade script from 2.x to 3.1 is trying to create it twice @bozana?
Before any upgrade attempt you should always backup both the database and the files (OJS files and submission files). OJS3 upgrade will move things around in your files directory so after an unsuccesful upgrade attempt you should restore the files directory from the backup.
Have you started the new update on your clean OJS 2.4.x database i.e. the one before any update?
As @ajnyga said: "Before any upgrade attempt you should always backup both the database and the files (OJS files and submission files). OJS3 upgrade will move things around in your files directory so after an unsuccesful upgrade attempt you should restore the files directory from the backup."
This also gilts for the DB.
I have a quick question. We took a backup for 10 journals and the size was 150 gb. Now Server space is very less, so we are thinking to download the backup files to our local system and migrate the same to OJS 3 on our local system for testing. Will this work on our local system. We have installed OJS2 and OJS3 separately to test this and they are working fine. So our doubt is if the migration will happen successfully on local system. Also will all the issue files will convert to latest version or I have to manually download the XML file and change the tag.
The OJS2 Guide describes both backing up the “System Files” and the “files/ Directory”. The “System Files” backup includes both the OJS application files and the “public” files directory.
A backup which includes the following will allow you to build a fresh copy of OJS, either at the current version, or a later version:
The OJS database
The OJS private files (files_dir)
The OJS public files (“public”)
You do not need the old OJS application files to build the 2.x installation first in a 3.x migration. You can extract the database, private files, public files, and config.inc.php directly from your 2.4.x backup within a fresh install of 3.x.
This is essentially what is described in the UPGRADE.md document, starting with the “Full Package” section:
Be sure to continue on to the “Upgrading the OJS Database” section, where the process will modify your database and the files in files_dir:
If you have access to the command line, we strongly recommend using that method, as everything can be logged. Without that, I think we would need to make a code change to log the web process to your PHP error log or to the files_dir.
In the installed directory of the actual application(which is in OJS 2.4) contain many other custom directories which are not part of default OJS 3.x. But i only copied “public” directory and config.inc.php in to the OJS 3.x installed directory.
But, no setting value that I know of will prevent the upgrade tool from displaying anything at all, as you are seeing. One possible exception could be the database driver, which when changing from PHP 5.x to PHP 7.x must change from “mysql” to “mysqli”. Otherwise, changing your settings within config.inc.php, including private_files and base_url should not cause the problem.
Copying the public directory and the config.inc.php into a fresh install of OJS 3.x should work.
I’m not seeing a good reason for why there would be no output from running the upgrade script.
As an remote possibility, perhaps your CLI instance of PHP is logging PHP error messages to a file rather than to STDERR, and a PHP level error (such as using “mysql” instead of “mysqli”) is being logged to that file rather than to the screen. Or perhaps the CLI is configured to suppress all PHP errors? We can check this by running:
and looking for values for “display_startup_errors”, “error_log”, and “error_reporting”.