I installed OJS in my VM and just made it into a subdomain over HTTPS
But in my Dashboard, I realized that I can’t edit most of the stuffs there
And I tried to inspect element to see what is wrong, and it shows
“Mixed Content: The page at ‘https://[myweb]/management/settings/website’ was loaded over HTTPS, but requested an insecure stylesheet ‘http://[myvmIP]/plugins/generic/tinymce/styles/content.css’. This request has been blocked; the content must be served over HTTPS.”
I am using OJS 3.4.0.5
Here’s the screenshot of what I opened from inspect element
Hi @Heat_Memory, what is the base_url
set as in your config.inc.php
file? Is it using https in the URL?
Yeah, it is using https

I also use the base_url for index and my journal
Hi @Heat_Memory, is force_ssl
set to On
in your config.inc.php
as well? You will also want to clear your template caches after changing these settings (in the Administration area).
Sorry, I just returned from a trip, but no, I don’t set force_ssl to On, if I set it, it will make an infinite redirect loop for some reason
Hi @Heat_Memory
You can try to apply this method, edit the file lib/pkp/classes/core/PKPRequest.inc.php to change this line:
$_this->_protocol = (!isset($_SERVER['HTTPS']) || strtolower_codesafe($_SERVER['HTTPS']) != 'on') ? 'http' : 'https';
to this:
$_this->_protocol = (!isset($_SERVER['HTTPS']) || strtolower_codesafe($_SERVER['HTTPS']) != 'on') ? 'https' : 'https';
In some cases this method works.
Regards
Almadani
I am having the same experience with infinite redirect loop when the force_ssl
to On
. In my case it’s the installation page. @Heat_Memory, which page(s) the infinite redirects happen?
@Muhammad_Al_Madani, I don’t think monkey patching with incorrect logic is a good way to solve this and may produce unintentional bug in the future.
In my case, the infinite redirects will happen in the journal management
@Muhammad_Al_Madani I will try your method later and informs you back if it works
I tried it, and it became similar to how it is when I activate force_ssl to On
Instead of patching application code (which you always have to maintain for each OJS upgrade), it is better to implement permanent redirect from http to https in the Apache configuration. This way, browsers and bots are also notified to use https in subsequent calls.
E.g. the http config file for apache looks like:
<VirtualHost *:80>
ServerAdmin ...
ServerName ...
ServerAlias ...
RewriteEngine On
RewriteCond %{HTTPS} !=on
RewriteRule ^/?(.*) https://%{SERVER_NAME}/$1 [L,R=301,QSA]
</VirtualHost>
The https config file contains:
<VirtualHost *:443>
DocumentRoot "{path-to-ojs-root}"
ServerAdmin ...
ServerName ...
ServerAlias ...
Header set Strict-Transport-Security "max-age=15780000"
...
The Header statements tells the browser to always use https in the future.
@Heat_Memory If you have an infinite redirect loop with force_ssl On (which is correct to set this way), this may point to a mistake in your Redirect rules in the Apache config or in the .htaccess file.
Also, in your config.inc.php:
base_url[index] should point to the same URL as in base_url above (it’s the base_url of your site, not the journal)
base_url[journalpath] should map either to base_url/journalpath or a different domain
Your redirect problem may be caused by your wrong configuration in config.inc.php as you showed above. In your site settings, did you set the redirect to a journal?
As an example for a config.inc.php:
; Base URL override settings: Entries like the following examples can
; be used to override the base URLs used by OJS. If you want to use a
; proxy to rewrite URLs to OJS, configure your proxy's URL with this format.
; Syntax: base_url[journal_path] = http://www.example.com
;
; Example1: URLs that aren't part of a particular journal.
; Example1: base_url[index] = http://www.example.com
; Example2: URLs that map to a subdirectory.
; Example2: base_url[myJournal] = http://www.example.com/myJournal
; Example3: URLs that map to a subdomain.
; Example3: base_url[myOtherJournal] = http://myOtherJournal.example.com
base_url[index] = https://www.hope.uzh.ch
base_url[altrelettere] = https://www.altrelettere.uzh.ch
base_url[bothros] = https://www.hope.uzh.ch/bothros
base_url[conexus] = https://www.hope.uzh.ch/conexus
base_url[ccr] = https://journal.computationalcommunication.org
base_url[doca] = https://www.hope.uzh.ch/doca
base_url[ejhc] = https://ejhc.org
...
That is kind of not the problem, the problem is the CSS stylesheet (and only the CSS stylesheet) is loaded with my VM IP address rather than my base_url, I tried inspecting element and edited where they are loaded from (for example the image) to my base_url, and it works, but for some reason they keep trying to load it from my VM IP Address
Is there a configuration file for these CSS that I can edit?