Reputation: 55
I'm trying to deploy the latest mediawiki image (1.42.3) but I have a pre-Dockerized and slightly outdated LocalSettings.php
(I did not run the install script because I have an existing database, although I did run maintenance/update.php
). The main problem is that I'm getting no styles or scripts, but I can see my articles and other pages. This is because, as shown by my browser console, the request for load.php
returns 404
. So when it tries to render the stylesheet, it thinks that "Load.php"
is an article and passes HTML where CSS/JS is expected. Here are the relevant settings:
$wgScriptPath = "/wiki";
$wgArticlePath = "/wiki/$1";
$wgServer = "https://example.org";
Note, I'm using my actual domain and not "example.org". I've already tried other values for wgScriptPath
such as "/"
and "/w"
. The image puts the mediawiki installation at /var/www/html
inside the container. Note that my intended access path for the wiki is at https://example.org/wiki
.
I'm not sure if the problem is with URL rewrites or with my NGINX configuration. In the mediawiki image, apache is purportedly preconfigured for URL rewrites. And here is my reverse proxy configuration:
location /wiki {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
proxy_set_header X-Forwarded-Proto $scheme;
}
Note: 8080 is mapped onto 80 (apache server in mediawiki container).
Please let me know what you think.
Upvotes: 0
Views: 74
Reputation: 55
I went for an alternative solution. Switched to the mediawiki:stable-fpm image and modified my nginx to include a php block inside the /wiki
location
location ~ \.php$ {
include fastcgi_params;
fastcgi_pass 127.0.0.1:9000;
fastcgi_split_path_info ^/wiki(.+\.php)(.*)$;
fastcgi_param SCRIPT_FILENAME /var/www/html$fastcgi_script_name;
// also passing PATH_INFO, SERVER_NAME, SERVER_PROTOCOL in a straightforward manner
}
You also have to mount the following wiki directories as bind mounts on Docker (and serve them on nginx): /images/
, /resources/assets/
, also some skin assets depending on which skin you use.
You can also extend the image to build with extensions.
All together, this setup is working for me. However, it feels hacky because mediawiki expects several different directories to be statically served, which conflicts with what the Docker project seeks to accomplish. You can expect random assets to be missing and all you can do is create a bind mount for whichever directory holds those assets, which means you will also have to supply the files themselves for those mounts.
If you happen to know an elegant solution for this problem please do post an answer.
Upvotes: 0