Hello everyone,
we are having a problem with OJS 3.3.0.13 using Docker and Apache2, when exposing the container at a sub-path of the domain,.
The Journal home-page is: https:///www.example.com/sub-path/index.php/exampleJournal
The Frontend works, but we can’t submit forms in the Backend.
POST request from the domain root returns 301 and redirect into GET to a sub-path of the domain:
Any idea how to correctly tunnel the POST request to the container?
Hi @ojsbsb
Last images I got time to properly test were 3.3.0-11, so I can’t confirm 12 to 14 are really working, but I didn’t introduce any changes in 13, so they are supposed to work as fine as 11. The only one I know is failing 3.3.0-14 that I can confirm is broken because I couldn’t manage to build it properly (and probably also because it’s the first one with php 8.1?)
I’m kind of overwhelmed till the end of the month to help with this but if you (or somebody) manage to find a fix and forward a PR (to gitLab) I can find a hole to rebuild the images (in gitLab, as far as dockerHub is not going to be free any more).
I’m so sorry. We decided to remake the whole docker project but I can’t find time to properly lead with this. If somebody got the time of the energy to play the role of locomotive, I will be happy to pass the baton.
Take care,
m.
Hi @marc - first of all, thanks a lot for all that work on dockerizing OJS. We are so happy that there actually is a docker image which takes us this far!
(Our team has been through the process of creating a docker image for another publishing software from scratch - so we were really glad to see that a lot of this work was already done for OJS.)
We are posting about our problems here not just to say it doesn’t work, but also because we thought someone reading this might already have used the docker images to deploy and expose OJS using apache.
Obviously, the issue in this thread - that POST requests become GET requests as they are tunneled to the docker container - could be related to the host Apache as well…
Apologies if I sounded too depressive.
It’s a mixture of work overtaking you and not wanting to get in the way if there are people with more energy. 
I don’t know if it will help you (maybe others who use docker can share their experience), but in the past I’ve had problems writing redirect rules that work correctly behind a proxy (the standard rules didn’t work for me) and with the way OJS builds URLs…
My solution, after a lot of trial and error, consists of a combination of rules and overwriting the index.php so that OJS assumes the base_url that I indicate (instead of trying to find it out).
Here’s an example of how I have a journal on a subpath, specifically for: https://revistes.uab.cat/brumal
For index.php (that looks like is working fine in your side):
$journalPath='brumal';
$_SERVER['SCRIPT_NAME'] = '/'. $journalPath . $_SERVER['SCRIPT_NAME'];
$_SERVER['PHP_SELF'] = '/'. $journalPath . $_SERVER['PHP_SELF'];
// Initialize global environment
define('INDEX_FILE_LOCATION', __FILE__);
$application = require('./lib/pkp/includes/bootstrap.inc.php');
// Serve the request
$application->execute();
Most relevant variables in config.inc.php (ojs 3.2) are:
base_url[index] = https://revistes.uab.cat/brumal/index
base_url[brumal] = https://revistes.uab.cat/brumal
trust_x_forwarded_for = On
force_ssl = Off
restful_urls = On
And Apache virtual host is:
LoadModule slotmem_shm_module modules/mod_slotmem_shm.so
LoadModule rewrite_module modules/mod_rewrite.so
LoadModule expires_module modules/mod_expires.so
<VirtualHost *:80>
ServerName revistes.uab.cat
ServerAlias revistes.uab.es
DocumentRoot /var/www/html
DirectoryIndex index.php index.html
RewriteEngine On
AcceptPathInfo On
SetEnv HTTPS On
<Directory /var/www/html>
# Redirect root to index
RewriteRule ^/?$ index.php/brumal/index [L=307]
RewriteRule ^brumal$ index.php/brumal/index [L=307]
# Bloc admin pages with DB info:
## RewriteRule ^/?brumal/index/admin/systemInfo/?$ /brumal/index [L]
## Force httpS (basically to reach the API):
RewriteCond %{HTTPS} !=on
RewriteCond %{REQUEST_URI} ^/brumal\/api\/v1\/
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^/?(.*) https://%{SERVER_NAME}/brumal/index.php/$1 [L,R=307]
# OJS expects to be at root, so removing journal's subdomain:
RewriteCond %{REQUEST_URI} ^/brumal
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^brumal/(.*)$ $1 [QSA,L]
## Rewrite API calls if not including subdomain journals:
RewriteCond %{REQUEST_URI} api\/v1\/
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ brumal/index.php/brumal/$1 [L,R=307]
# Renames the short journal's rule:
RewriteCond %{REQUEST_URI} !^index.php\/brumal
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php/brumal/$1 [QSA,L]
# This removes index.php from the url (apache 2.2 and new ones)
RewriteCond %{REQUEST_URI} !^/brumal/index.php
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-d
RewriteCond %{DOCUMENT_ROOT}%{REQUEST_URI} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*)$ index.php/$1 [QSA,L]
</Directory>
# LogLevel alert rewrite:trace2
ErrorLog /var/log/apache2/error.log
CustomLog /var/log/apache2/access.log combined
Take in consideration:
TL;DR; IMO, this is a mod_rewrite issue… that by the way, it’s one of the most complex problems I always find in OJS… and I would love to find some basic configs to include in the docker images “out-of-the-box” (ie: domain, subdomain, subdomain+path deeply tested examples).
You will probably like to join this gitHub Discussion:
@AndrewGearhart dealed with this recently so he will probably could help you more than me with this.
Take care and keep in touch,
m.
Hi @ojsbsb
We are on vacations now, so I have some time to dig into this.
Any further clue about why it happens? Did you manage to find a solution?
Not sure how it could be related with the issue you reported, but the main difference between -13 and -14 is the php version (as php deprecated 7.4 I moved to 8.1) but according to @jonasraoni 3.3. is not still ready for php8 so I think we will need to roll back to 7.4. Please Jonas… do you mind to confirm?
I will also generate 3.4-RC2 images during this week (over php 8.1 in this case).
Thanks for the patience,
m.
3.3.0-14 (over php7.4) and 3.4-rc2 (over php8.1) images created and pushed to dockerHub.
If somebody got time to test them feedback is really welcome.
I will try to test them by my own during the week.
Cheers,
m.
@marc OJS 3.3 has tests covering PHP 8.0 and 8.1, but the introduction of PHP 8.1 for example is recent (pkp/pkp-lib#7690 Add PHP8.1 testing · pkp/ojs@d9bf12a · GitHub).
As the tests are not covering the whole codebase, it means that maybe you’ll face something unexpected. On another hand, PHP 7.4 is already battle tested against OJS 3.3 
The same applies for the plugins, for example the customLocale, only have tests against PHP 7.3 and 7.4: #18 Overrode getSeq() method in order to give a higher load priority for this plugin · pkp/customLocale@e745097 · GitHub.
Best,
Jonas Raoni
As always, thank you Jonas for being so generous and accurate with your knowledge.
About the images: I made a clean installation and they both work great.
I still need to test them on production… to see if they play gently in with the reverse proxy, the plugins, the upgrade… but so far so good.
Please @ojsbsb tell us if you are still in trouble with this new 3.3.0-14 image running with php7.4.
Take care,
m.
Hi all,
Just a note about PHP versions – with PHP supported versions currently listing 7.x as unmaintained and 8.0 only maintained for security, I’d like to make sure PKP software does support current PHP releases (8.1 and 8.2) well. I’ve added automated tests for PHP8.2 to the forthcoming 3.4 release, and am just about to do the same for 3.3.0-15 and later.
OJS/OMP/OPS 3.3.0-x do support PHP 8.0 and 8.1 well, but I think there are still a few plugins out there that don’t. If you run into one of these, please check your PHP error log for details. Please post on the forum or contact the plugin author when you encounter these! It’ll help ensure everything gets fixed ASAP.
I don’t recommend that folks still rely on anything older than PHP 8.0; many distributions still support 7.x, but it’s past end-of-life according to the PHP project, and I trust them on it!
Regards,
Alec Smecher
Public Knowledge Project Team
@marc hi there,
I tried this solution and a few others but it doesn’t work, so for now we set up our docker instance ojs.3.3.0-13 without subpath. That works well. I may come back to this later.
Interestingly, the home page works with the subpath, but when I click on one of the journals (we have 2 journals on that instance), the subpath disappears.
If I manually write the path with subpath it also works. But if I then click on one of the links in the header - it’s gone.
if I configure in apache that the journals also have a subpath, then we have this initial problem with the POST request.
Hi @ojsbsb
Let me ask you directly to see if we can narrow the problem.
If I had to bet, I’d wager that it’s a problem with your redirections (I myself have wasted a lot of time on my own installation to get a working combination behind my reverse proxy), so I will try to help but I will assume the problem is not in the docker images.
About php7.4… we have been talking about it with PKP and we all agree we need to move to (at least) php81. Alec is going to release a 3.3.0-15 very soon so, if nobody is against it, I will build this new image with php 8.1.
An alternative is keeping images with different php flavors… that I’m not against (build script is ready for this) but I’m unsure if this will be useful for anybody.
Cheers,
m.
Hi all,
Just to note that PHP7.4 will still be stable with OJS 3.3.0-x. However, it’s long past its end of life according to the PHP project, and I think we should be discouraging its ongoing use for that reason.
Regards,
Alec Smecher
Public Knowledge Project Team
This topic was automatically closed 21 days after the last reply. New replies are no longer allowed.