Two different OJS URLs after upgrading from to

Describe the issue or problem

After a successful upgrade from OJS- to OJS- many small issues appeared that interfere with the normal functioning of the OJS. I suspect these issues were present in our old installation of OJS- and carried on through all upgrades, which were done stepwise. After careful analysis, we are pretty sure that all of the issues originate from two different URLs existing in OJS code. One URL is “https://www.MyJournal…” and another is “https://MyJournal…” Sometimes OJS directs users to pages with the URL starting with www and sometimes to pages without www in URL. Sometimes in the email messages sent from the OJS, inserted URLs have www in the address and sometimes do not. To complicate things further, there are also URLs that start with HTTP instead of https.

The problems always appear when the users are directed to the pages with www. Sometimes PHP errors are generated, sometimes there is a glitch in the user pages. The problem with Orcid described here: ORCID redirect URI suddenly does not match was also caused by sending URL starting with www. Interesting point is also that even the font and paragraph formatings are different when we go to https://www.MyJournal from the https://MyJournal.

Steps I took leading up to the issue

I believe that HTTP/https problem should not be an issue since we have automatic https redirection installed. But we really do not know what triggers OJS to point to either one, www or no-www URLs, and when. And why do we have problems with www URLs? We installed our own child template but it does not seem to be the origin of the problem, especially because we used the same child template in the previous OJS-3-1-2-4, which worked perfectly.

I am wondering how to solve this issue. Would that be ok to go through the code and replace all instances of https://www.MyJournal with https://MyJournal?

Any response would be greatly appreciated.

I wonder why there is no response to this post. If somebody could give a hint, this would indeed be a great help.

Hi @zmandic

I wonder why there is no response to this post.

When it happens, usually it’s because any of all of this:
a) Problem is not clear enough.
b) The question is not trivial.
c) People have their hands full.

So please, be patient.

After careful analysis, we are pretty sure that all of the issues originate from two different URLs existing in OJS code.

Without further information, my first bet would suggest you to double check the content created by you or your editors. Let’s say that you have content published in your About page… and this content adds a link to an internal OJS page. This link could have relative or absolute urls… and in the second case, if http is forced (instead of httpS), OJS won’t change it in your behalf. And same will happen with the www prefix.

You have multiple ways to check your content looking for wrong urls. If I had to check this I will probably use a db dump and use grep to look for url patterns.

If is not the case, try to identify better who/when are created the wrong urls and report it back.


Hi @marc

Thank you very much for your response. I apologize for trying to force the response. I did not mean to put pressure or to be annoying.

I am pretty sure the issue came up with the new installation of OJS- Maybe, the issue was present in earlier versions of OJS but, if so, the issue was not apparent.

The problem is not in the content created by the editors since it would be easily corrected. There must be something going behind the scene. To reinforce this point I can give two examples:

  1. {$contextUrl} and {$submissionUrl} in email template messages always append “www” in the address. However, it seems that {$Url} pulls out the correct address without “www”.
  2. In the previous versions of OJS the correct domain name without “www” was sent to Orcid when the users were automatically directed for the Orcid number registration. However, after upgrading to ver. the domain name which is sent to Orcid includes www.

We have correctly set the base_url in the to address without “www”. It looks very strange to me. I cannot see why the system pulls out the wrong address from the system and why it does so starting from OJS-…

We have correctly configured the base-url in

Kind regards,


Hi @zmandic

Sorry for the annoyance, but I need to ask the basics first to be sure.

As far I know, problem could (from easy to complex) in:

  1. [x] content
  2. [_] variables
  3. [_] caching (server o client side)
  4. [_] webserver (ie: mod_rewrite rules)
  5. [_] database (harcoded urls somewhere… like in email_templates)
  6. [_] infrastructure (an firewall is taking decisions in your behalf)

If 1 is ok, let’s go with number 2 then.

Do you mind to copy here your base_url variables?
force_ssl and any other url-related variable would be also appreciated.

If you prefer, you can upload an anonymized version of your to and copy the url here.


Hi @marc ,

here it is: (hidden)

Kind regards,


Hi @zmandic,

I’ve hidden that link because it still contained a couple of API keys/credential sets.

Alec Smecher
Public Knowledge Project Team

1 Like

Thanks Alec.

An anonymized version of pastebin is here:

@zmandic I don’t see anything wired in your and I visited your site and all looks fine to me.

Do you have any example of public urls that include a wrong domain?

Hi @marc ,

Generally, I would not bother with the wrong domains if they did not bring a headache. There are many instances where they cause problems. First of all, please try to compare the Home page of one of the journals with and without “www”. You will notice that font and paragraph formatting are completely different. In addition, sometimes PHP errors appear on the top of the loaded pages when the pages starting with “www” are loaded. Sometimes there is a glitch in the user pages when the website is loaded with URL starting with “www”.

Below are some examples to demonstrate the calling of the wrong domain:

  1. the notification messages use variables {$submissionURL} and {$contextURL}. Below is copy/paste of one of the notification messages. You’ll notice that the {$submissionURL} appended www in the address.

You have a new notification from Journal of …:
There is new activity in the discussion titled “Corrected COPYEDITED” regarding the submission “Understanding the annealing effect on…”.
jESE Editorial Office

  1. Immediately after the upgrade to OJS3.3.0.13, Orcid started refusing our domain name (please check this post: ORCID redirect URI suddenly does not match). This was because the registered domain name in Orcid was the one without the “www”. Once we added an additional domain name starting with “www”, Orcid started to function properly again. This means that before the upgrade to OJS3.3.0.13 we had base URL without “www” but after the upgrade we have the base address with “www”.

  2. There are some relative URL links in the editorial content, many of these (or all of them) point to the www address.

I hope I explained this better.

Kind regards and many thanks for your attention.

Hi @zmandic,

Now I understand.

  • When you visit your site with the “www” prefix all works as expected.
  • When you visit your site without the prefix, OJS is building a html a mix of domains and won’t load any resource with the “www” prefix.

In second case, if you take a look to the error shown in your browser, you will see it refers the error as “CORS Missing Allow Orign”:

Here you have a detailed description:

So, looks like the problem is caused by your theme, that hardcode the domain.

You can fix this with different approaches:
0. Clear your browser’s and server’s OJS cache (see below).

  1. Change your to tell OJS to force base_url to be “” (not sure if this will work, but it’s the easiest to try)
  2. Change your theme to use relative urls.
  3. Change your webserver to Allow-Origin from both domains.
  4. Change your webserver with redirections to force one of both domains (all without or without www).

I sort them from easier to more complex, so try them by order.

Please tell us how it goes,

1 Like

Hi @marc,
Thank you very much for your time and input.
I would like to let you know that we solved the problem with rewrite rule. The theme was ok.
I do not understand it completely but, probably, after some time, when all caches are cleared, it will continue normally.
Thank you once again.

1 Like

Thanks for the feedback.

I will change my former answer to add the “clear server caches” as first point of the list, then.

You can force it in the OJS interface, but I prefer doing it directly in the server, removing cache content as follows:

CACHEPATH=/var/www/html/cache \
&& find ${CACHEPATH:-/tmp} -type f -delete && ls -lisaR ${CACHEPATH:-/tmp}

Rename the variable to point to your /cache folder and enjoy.