Could someone with deep experience take a look at the following procedure and tell me what I’m doing wrong? The server we are using is sufficiently robust that we should not have encountered any time-outs or run up against other restrictions during the upgrade process.
I am carefully trying to avoid an upgrade approach which would overwrite the current database and code since we had one other bad experience about one year ago before we moved to FastComet. This is why I’m attempting to use the 3.1.0-1 code in a separate directory with a lone of the database. These are the steps that I followed. This is for the submissions system of a journal, TESL-EJ.org which has been publishing for over 25 years.
I cloned the existing database (ejojs) and created another called “ejojs2018”. There is one place in database, a table called “Journals” that needs to have “ejojs” altered to the new directory name, “ejojs2018” or clicks will make the screen jump back t the current (old) system. [Did I miss somewhere else?]
I downloaded a tarball of the code (ojs-3.1.0-1.tar), which is still there in the public html directory.
I created a new directory, “ejojs2018” with the new code.
I took the “config.inc.php” file from the current site and put it into the directory with the new code. I then changed the particulars to match the cloned database:
[database]
driver = mysql
host = localhost
username = teslejsu_ejojs18 (It seems that there is a length limit on names, which is why this says only “18” not “2018”)
password = xxxxxxxxxx (I used the PW we use for logging in to FastComet just to keep it simple for now…)
name = teslejsu_ejojs2018
I changed “Installed = On” to "Installed = “Off” and re-saved the config.inc.php file following these steps (from the “UPGRADE” file in ejojs2018/docs
- Edit config.inc.php and change "installed = On" to "installed = Off"
- Run the following command from the OJS directory (not including the $):
$ php tools/upgrade.php upgrade
- Re-edit config.inc.php and change "installed = Off" back to
"installed = On"
I then accessed the new site (http://teslej-sub.org/ejojs2018) and followed the prompts, Clicking on “If you are upgrading an existing installation, click here.”
The installation process started but died with an HTTP 500 error. The database was updated, at least to some extent because there were 5 new tables related to “navigation_menus” that had not existed before.
For the error itself, check your php error log after the upgrade attempt. You should find more details about the error there.
Other things I noticed:
You should copy your existing public-folder as well to the new installation folder you created the same way you did with the config.inc.php file.
I would also make a copy of the files folder and use the copy for the upgrade. The upgrade script does changes to the files folder as well (not 100% sure if the changes are made from 3.0.2 to 3.1.0. but not in 3.1.0. to 3.1.0.1. like in your case, but doing a copy of the files folder for the upgrade is a good practice anyway). This way you can always revert back to an old copy of the database and the files folder if the upgrade fails.
When you say you followed the steps you pasted there, did you run the upgrade from the command line (used php tools/upgrade.php upgrade)? Because it seems that you then tried to run the upgrade also using the web based upgrade process (If you are upgrading an existing installation, click here.)?
The php error log did not provide any useful information.
Yes, I did copy the file directory, which we have located at the same level of the public_html directory so that it isn’t available on the web. But actually, sorry, I did NOT copy over the “public” folder within the OJS structure, so that was missing. Perhaps that was the problem!
I actually ran “php tools/upgrade.php upgrade” from both the command line and using the web-based upgrade function.
I made an assumption that if there were two parallel directories for the code, two parallel databases and two parallel file directories (and public folders), that I can keep the old one alive until I decide to rename the directories. In other words, right now there are the original, /ejosj and /ejosj2018 which I would rename to /ejosjold and /ejosj This assumption is valid, isn’t it?
It allow continuous use of the old site until the new one is available. Of course, ideally, the current site should be taken off line so that there will be no changes in the data while cloning it.
I think that your assumption sounds right. We usually first clone our whole installation to a test server and run the upgrade there. Usually we have to fix some data in the database during these test runs because we have a lot of journals with a lot of old content and some data seems to get corrupted over time due to various reasons. When we have enough knowledge of the upgrade, we close down our production server (change the apache settings to serve another directory with a maintenance message) and then run the command line based upgrade. As you said, if you let people access your production server while upgrading it, it could lead to some problems.
I do not think that you need to run the web based upgrade after you have done it from the command line.
I suggest that you do another upgrade attempt and this time add the copy of the public folder there as well.
In config.inc.php make sure that you change the database name to the copy, that the files directory setting is pointing to the copy of files directory and that your base_url setting is pointing to the testfolder you are using.
Make sure that the files directory, cache directory and the public directory are readable and writable. If you run the upgrade with root permissions, it should work anyway, but after the upgrade the folders have to be readable and writable also for the apache user (what this means depends on your server, see How should file permissions be set?)
After the upgrade make sure you change installed to On.