OJS outputs bad DOI link

Hello! We just published our first article since migrating our site from an old install with old software We used the Quick submission tool for all our backs issue, which did not have DOI’s and the system generated good links for all. With this latest article, which went trough the publishing process in the new install, a .www is inserted in to DOI url, making a click on the link return the 400 error. Our base url is the system config does not have the www.

Describe the issue or problem
DOI Link returns a 400 bad request error.

Steps I took leading up to the issue

A DOI number was not auto-generated upon publishing this issue/article.
I used the “Assign DOIs” option in the DOI plugin to manually generate the DOI number

What application are you using?

Page with bad link

How do I fix this?
THanks in advance.

Is the resolver plugin enabled?

The Public Info Resolver? It is not installed.

The gateway resolver. But that was a wrong hint.

Your article is on https://ejssm.com/ojs/index.php/site/article/view/88

However, your DOI resolves to https://www.ejssm.com/ojs/index.php/site/article/view/88

It seems that your Web server is missing a Redirect rule.

That might very well be, however why would the rest of the articles links be working no problem?

Because they were deposited differently?

http://api.crossref.org/works/10.55599/ejssm.v18i1.88 lists the URL with www (see links and resource entries).
http://api.crossref.org/works/10.55599/ejssm.v17i3.83 lists the URL without www.

Did you (or another person) deposit manually? By chance one was on www.ejssm.com when the deposit for the upper article was done?

You could re-deposit the affected article using the Crossref XML Export. But my recommendation is also to check the Rewrite rules of your web server and to decide which one is the canonical base URL - the one with www or the one without.

Thanks so much for all your responses.

The problem article DOI was deposited via OJS in the same way as the archived articles.

However, upon more testing, it’s this does look like this is a server redirect problem. It’s just odd that it shows up now, after zero problems with all the archive articles and no other links on the site suffer a similar problem. I will check with the host and see what they have to say.

Thanks again!