Nothing happens when trying to upgrade to OJS 2.4.8.-5

rifp · March 2, 2025, 2:40pm

Describe the issue or problem
I have to upgrade an old OJS installation from version 2.4.8-3 to a recent 3.x.x version.
As a first step, I want to upgrade to the last 2.x.x version, namely 2.4.8-5. From there I
want to move to 3.2.1-5 and then to a more recent 3.x.x version.

When trying to upgrade to 2.4.8-5, nothing happens.

Steps I took leading up to the issue

I have uploaded ojs-2.4.8-5 on the server of my service provider.
When I open the main page, OJS correctly shows the installation page.
On that page, I have clicked on the upgrade link, which points to ojs-2.4.8-5/index.php/index/install/upgrade (relative to my site’s root path).
On the new page, I have clicked on the Upgrade Open Journal Systems button.
There was no response for more than 20 seconds.
Afterwards, the browser stopped loading and stayed on the upgrade page.
I had expected to land on a success page (I had performed a test installation on a local laptop before).

What application are you using?
OJS 2.4.8-5

Additional information
The directory layout on the productive webserver is the following:

The folder ojs contains the current productive installation
The folder ojs-2.4.8-5 contains the new OJS system I am trying to install.
The two installations use disjoint document folders (files_dir) and separate databases.
In case this is relevant, the root folder contains a file index.php which redirects to the productive OJS installation under ojs.

After attempting the upgrade, I see an error in the server log: 02/03/2025 14:03:50 [error] [client 95.33.122.91] - www.mydomain.com - AH00687: Negotiation: discovered file(s) matching request: /web/htdocs/www.mydomain.com/home/index (None could be negotiated)., referer https://www.mydomain.com/ojs-2.4.8-5/index.php/index/install/upgrade

Note that the document root folder of the web server is

/web/htdocs/www.mydomain.com/home

So, for some reason, the installation procedure at

/ojs-2.4.8-5/index.php/index/install/upgrade

is trying to access the path

/index

which is outside its root folder.
This is where I stopped my analysis: I think OJS trying to access a path outside its installation folder could explain the problem, but I have no clue as to why this is happening.

Also, I have checked my PHP execution time (max_execution_time in the ini file) is high enough: max_execution_time = 900

Could you give me some hint?

asmecher · March 3, 2025, 2:56pm

Hi @rifp,

Did you successfully locate your PHP error log? There will almost always be something there to indicate what went wrong during an upgrade.

If it’s possible, I would also recommend using the command-line upgrade tool (tools/upgrade.php) rather than the web-based upgrader. It’s must more reliable, especially for long-running upgrades, as your 2.x to 3.x is likely to be.

Regards,
Alec Smecher
Public Knowledge Project Team

rifp · March 3, 2025, 7:52pm

Hi Alec,

thanks for you answer.

My account with the service provider does not give me direct access to the server’s logs,
and I do not have a shell login in which I can run the upgrade script from the command line. I can only upload a complete OJS folder via FTP and run the migration from the
browser. This had worked fine up to now: We had performed several migrations in this
way.

The service provider offers a control panel in which I can view the error log of the web
server. In this log I can see the error I mentioned in my original post: The upgrade
procedure is trying to access a file outside its installation folder. As far as I understand,
this should not happen, since an OJS installation should only access files inside its
installation folder and inside the data folder. I have

base_url = "https://www.mydomain.com/ojs-2.4.8-5"
files_dir = "/web/htdocs/www.mydomain.com/home/app_data_2.4.8-5/files"

Since the web server maps www.mydomain.com to

/web/htdocs/www.mydomain.com/home

I would expect the upgrade procedure to access only files that
are under

/web/htdocs/www.mydomain.com/home/ojs-2.4.8-5
/web/htdocs/www.mydomain.com/home/app_data_2.4.8-5/files

On the other hand, the error I have posted shows that the upgrade script
tries to access the root folder, namely

/web/htdocs/www.mydomain.com/home/index

As far as I understand, this leads to an error because there is no file named index
in the root folder.

So can it be that the upgrade procedures tries to access the root folder? Maybe
it just tries to open www.mydomain.com/index? Maybe I have forgotten to set
some configuration variable besides base_url and files_dir?
If this is a feature and is not due to a misconfiguration on my side, I will have
to figure out another solution.

I can also try and ask the service provider to give me access to the
complete server logs but, as far as I know, this would mean to move to
a different service contract.

Thanks again and best regards,

Giorgio

asmecher · March 3, 2025, 10:11pm

Hi @rifp,

I think the message…

[error] [client 95.33.122.91] - www.mydomain.com - AH00687: Negotiation: discovered file(s) matching request: /web/htdocs/www.mydomain.com/home/index (None could be negotiated)., referer https://www.mydomain.com/ojs-2.4.8-5/index.php/index/install/upgrade

…is probably a red herring. Do you have base_url[...] settings configured in your config.inc.php file? Do you have restful_urls turned on? If so, those settings require a working mod_rewrite configuration, either in your Apache config or your .htaccess file, otherwise they won’t work. But I’m not sure that’s what’s happening here.

In any case, the AH00687 message is coming from the Apache error log, which is not always the same thing as the PHP error log. I suspect the error message you’re looking for is in the PHP error log.

It’s pretty unusual to not have good access to the logs, and most hosts do give SSH access – but if yours doesn’t, another option might be to download a database backup and copy of the files to your local machine (or another server) and run the upgrade process there, where you have better access to the things you’ll need.

Regards,
Alec Smecher
Public Knowledge Project Team

rifp · March 4, 2025, 8:54pm

Hello Alec,

thanks again for the hints. I have already performed the migration by downloading a copy of the data folder and a dump of the database to a local VM. In my local VM the migration worked without errors.

Would it make sense to perform the migration locally and then upload the migrated database + data folder to the productive server? Up to now I was reluctant to do this, because I thought the resulting database content might be incompatible with the productive environment, maybe due to different DBMS-versions or something like that.

If this can be ruled out I would try to perform the migration locally, i.e. I would

download (and backup) a database dump and a copy of the data folder,
perform the migration on a local VM,
upload the migrated database and data folder to the productive server.

Do you think this could work?

Thanks again and best regards,

Giorgio

asmecher · March 4, 2025, 9:00pm

Hi @rifp,

Yes, that’s the process I would recommend. Since you have a few upgrades in a row to manage, it’ll be much easier to do them where you have proper access to the system.

Note that we’re going to be releasing 3.5.0, which will become the basis for our next LTS line, within the next quarter. Once you get to 3.3.0, I’d suggest planning for an upgrade from there to 3.5.0. Once all of that is under your belt, you’ll be in good hands for the next 3-5 years.

Regards,
Alec Smecher
Public Knowledge Project Team