We’re preparing an upgrade from OJS-3.1.2 to OJS-3.2.0. Upgrading the database went without problems, and most of the OJS interface seems to be working smoothly. Yet, there’s one issue that at first glance seems to be related to the
base_url setting. Even though the
config.inc.php file lists a fully qualified URL:
base_url = "http://journal.domain.org/journalPath"
…it seems that OJS is generating Protocol-relative URLs from it (i.e. URLs starting with a double slash, omitting the HTTP part). I’m not sure if this is a feature or a quirk, but it is proving unhelpful in the context of e-mail notifications.
I’ll illustrate the problem by copying a fragment of an e-mail notification generated by OJS:
Review assignment updated.
Since the protocol is missing from this URL, this is rather unhelpful when viewed in the context of an e-mail client. First off, this protocol-relative URL in above message is not parsed as a link at all by Thunderbird, so users have to copy/paste it in a browser themselves (provided they won’t overlook the fact that the e-mail actually contains any links). Also, the link to the journal in the footer (which is displayed as a clickable link) does nothing when clicked, since the e-mail client doesn’t know what to do without any protocol in the URL. This is the case for all URLs being generated in the notification templates (
When checking the journal path in the OJS interface, via “Administration” > “Hosted Journals” > “Edit”, I find the
Path field pre-filled with this domain (also lacking the protocol). Yet, it is not editable.
This didn’t happen in OJS-3.1, so I’m wondering if this is expected behaviour in OJS-3.2 ? I can imagine it could be a strategy to make OJS agnostic of the context in which it is being deployed (HTTP vs HTTPS), so it will always produce working links on the website. Yet, for notification e-mails, this is a step back.
Or could it indicate some configuration issues that should be fixed on our side?