Transferring database and files between different installations and versions: 3.3.0.13 to 3.5.0.4

Greetings!

I have looked through the forums and found some helpful replies but they do not quite apply to our situation. Therefore, I would like to get your recommendations on approaching this “upgrade.” It is an upgrade since we are moving from 3.3.0.13 to 3.5.0.3 (or should I wait for 3.5.0.4 to become LTS?). In our case, I cannot just stop our publishers from doing their work in 3.3 until 3.5 is ready. I think there are two options:

  1. install 3.5.0.3 in a newly created subdomain and copy the files from the “active” directory to the new subdomain’s directory. Somewhere in the forum, I have come across warnings about file structure and database compatibility. I have actually created a clean installation of 3.5.0.3 free of the junk that has accumulated in our active directory. We are using cPanel provided by our hosts as we have no direct access to a server with the LAMP architecture. The cPanel is a LAMP-based setup except for access past the root level.

  2. use a sandbox approach whereby I clone the 3.3 installation in a newly created subdomain and then upgrade that one 3.5.0.3 so that the files and database are compatible with the new version. The main installation is in the public_html folder but the files are outside of it. Is there an OJS folder manifest to see what should really be in a good OJS installation?

The issue with this parallel approach is that when we are ready to move all publishers over, we have to update the database and add the new files that were created between the time of installation/sandbox upgrade and this final move, so I would have to stop all workflow processes. At least, this way they have a chance to see what their journal will look like and if we need new plugins or other customizations.

Is there yet a third method (other than Softaculous, which fails consistently with upgrades and even just first-time installations)?. Thank you in advance!

Arjun @asabhar

Hi @asabhar,

Running two installations in parallel sounds like a headache to me. I would recommend running a test upgrade process, and when you’re satisfied that it’s working as expected, discarding it and running the same upgrade process on a production environment. The downtime to your publishers should be measured in minutes.

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks, Alec. I only learned a little more about the process and realized that I can set the OJS in maintenance mode. I am also considering this approach to learn more about the upgrade process for future uses. I have your video to follow for the upgrade from 3.3.0.13 to 3.5.0.4, so that is one method I would like to learn. I have cloned by production environment (OJS 3.3.0.13) in a subdomain to do this. The other subdomain has 3.5.0.3 in it – a clean install – so I can at least see how the easier upgrade happens there. Right now, there is no pressing timeline because these journals are in session well into the summer, but I’d like to wrap this up by the end of the summer. So, I have a bit of time on my end to learn all I can. Ultimately, I am going to heed your advice. Your video is helpful, I just need to translate the steps as they need to work in a cPanel.

Question: for an OJS with 6 journals taking up about 6 GBs, do you recommend sendmail or SMTP? I have recently got our authentication working right with SMTP. Best!

–Arjun @asabhar

Hi @asabhar,

Sendmail and SMTP are just two roads to get to the mail server, which is probably the same software in both cases. Neither is better.

Regards,
Alec Smecher
Public Knowledge Project Team

Thanks, @asmecher

Thus far, SMTP is working out. I just have to work with the dmarc lines in the config.inc.php file. Leaving those lines uncommented leads to failed authentication.