Link structure OJS 2.x -> 3.x

Our current install of OJS currently uses links formatted as:

disable_path_info = OFF

A couple of months ago our server provider upgraded their server and broke the links. They were suddenly formatted as: Novus - Online tidsskrifter

disable_path_info = ON because the new server did not support this feature.

We are currently planning a move to OJS 3.x, but we are worried about being dependent on our server provider to NOT upgrade their server. Changing links is obviously not an option as that would break hundreds or thousands of referenced article URLs both online and in print. But our server provider might not be too keen on NOT upgrading either.

Currently our server provider moved our domain to a server that has not been upgraded. The reason we need to upgrade is that we are on 2.4.7 which requires php 5.x, and our server provider says they will have to upgrade php on all their servers in the near future and have just temporarily downgraded php from 7 to 5.

What to do? Can we upgrade to OJS 3, have our provider upgrade php and server environment and still be sure that our links will stay as


Hi @geirrosset,

I’d strongly recommend working with your service provider to see if you can get a configuration working that doesn’t require disable_path_info to be turned on. Essentially the normal structure of OJS URLs (the kind you used to have) depends on the CGI standard PATH_INFO variable, and it sounds like your server is not supporting it properly.

The disable_path_info option is a work-around for this scenario but it’s not perfect – the URLs are particularly ugly, and it slightly breaks our implementation of the OAI-PMH specification by including non-OAI-PMH query parameters. We’re likely to remove it at some point in the future, as it seems to be less common for environments not to support it than it was when we introduced the option.

It shouldn’t be necessary for the CGI PATH_INFO variable to break in order to upgrade to PHP 7.x; most ISPs run PHP 7.x and support the PATH_INFO variable without problems.

Alec Smecher
Public Knowledge Project Team