After a successful upgrade from OJS-3.1.2.4 to OJS-3.3.0.13 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-2.4.7.1 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?
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.
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-3.3.0.13. 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:
{$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”.
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. 3.3.0.13 the domain name which is sent to Orcid includes www.
We have correctly set the base_url in the config.inc.php 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-3.3.0.13…
We have correctly configured the base-url in config.inc.php.
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:
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…”. Link: https://www.pub.iapchem.org/ojs/index.php/JESE/… jESE Editorial Office
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”.
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.
Zoran
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.
Zoran