Noob questions for caddy docker

What Docker images are you using for WordPress and Nextcloud?

It’s likely unnecessary (maybe even detrimental?) for you to set fastcgi for those sites. Likely the Docker maintainer has configured PHP within the container.

Similarly your rewrite on the WordPress site is probably unnecessary as well, since you’re proxying to what is very likely a fully configured nginx within the WordPress container anyway.

By way of example, here’s my WordPress Caddyfile in entirety:

example.com {
  redir https://www.example.com{uri}
}

www.example.com {
  proxy / wordpress {
    transparent
  }
}

That’s all there is - the first site isn’t necessary either, it just catches people browsing to the bare domain instead of www.

I use the official WordPress container tagged php7.0, and it does access logging as well, so I personally don’t bother having Caddy logging too.

Wordpress:
I am using the official one too.
I changed my wordpress server part to your except the www thing.

docker run -it -d
–name wordpress
–restart=always
-p 8090:80
-e PUID=33 -e PGID=33
-e TZ=Europe/Berlin
-v /docker/data/caddy/www/wordpress:/var/www/html
wordpress

And I am still receiving this
2017-10-30 16_00_18-WordPress › Setup Configuration File

If I am trying internal address it looks as expected
2017-10-30 21_05_11-srv-docker int

This is the part, just to be sure, in Caddyfile:

myadress.my-wan.de {
#wordpress
proxy / 192.168.100.10:8090 {
transparent
}
tls mail@address.de
}

for nextcloud I am using this one:

docker run -it -d
–name nextcloud
–restart=always
-p 82:80
-p 4432:443
-e PUID=33 -e PGID=33
-e TZ=Europe/Berlin
-v /docker/config/nextcloud:/config
-v /docker/data/nextcloud/:/data
linuxserver/nextcloud

Looks like the style sheet didn’t download.

Try an incognito window, or open up the developer tools to the network tab & disable cache, and look for download errors.

the incognito window brought no change.
with dev tools I received this:

2017-10-31 10_08_27-WordPress › Setup Configuration File

Some lines to nextcloud. It is now working. For me there was a bug in the nginx site conf file from linuxserver. I asked alread for help in github on this one. This is now also working!!!

The only one to go wordpress …

Just to be sure my docker command for wordpress is right:

docker run -it -d \
  --name wordpress \
  --restart=always \
  -p 8090:80 \
  -e PUID=33 -e PGID=33 \
  -e TZ=Europe/Berlin \
  -v /docker/data/caddy/www/wordpress:/var/www/html  \
  wordpress

I don’t believe PUID, PGID or TZ environmental variables are used by the container, but that’s inconsequential (those flags would simply not have an appreciable effect).

There’s a list of possible vars on the Docker hub page:

https://hub.docker.com/_/wordpress/


The missing style sheet is still confusing. There should probably be an additional network request there, for a css document of some kind.

At this point I’d try mv /docker/data/caddy/www/wordpress{,.bak} and let Docker recreate the folder and re-download WordPress.

Hello Matthew,

I tried what you recommanded. Still same behaviour
with 192.168.100.10:8090 stylesheet is ok
with wordpress.myadress.de it is not loaded

Do you do your own docker compose/Dockerfile or do you just run worpress container as it is?

I read that some adjustments needed in wp-config.php … ??

:confused:

Add errors caddy.errors and log caddy.log to the WordPress site definition in your Caddyfile. Browse to wordpress.myaddress.de again, then check the logs for requests to find out exactly what your browser is (or isn’t) requesting from Caddy.


As for my WordPress container, I use Compose (for everything). I also keep separate compose files for separate projects, so this one is configured such that the WordPress container joins the existing Docker network containing my front-facing Caddy instance. This lets me get away with a neater proxy command in my Caddyfile, as shown above.

docker-compose.yml
version: '3'

services:
  wordpress:
    image: wordpress:php7.0
    depends_on:
      - wordpress-db
    environment:
      WORDPRESS_DB_PASSWORD: [snip]
      WORDPRESS_DB_HOST: wordpress-db
    volumes:
      - ./wordpress:/var/www/html
    networks:
      - default
      - frontend
    restart: always

  wordpress-db:
    image: mariadb:latest
    environment:
      MYSQL_ROOT_PASSWORD: [snip]
    volumes:
      - ./wordpress-db:/var/lib/mysql
    restart: always

networks:
  frontend:
    external:
      name: web_frontend
87.174.245.110 - - [01/Nov/2017:07:32:51 +0000] "GET / HTTP/2.0" 302 23
87.174.245.110 - - [01/Nov/2017:07:32:52 +0000] "GET /wp-admin/setup-config.php HTTP/2.0" 200 3732

no entry in errors

Hello,
I raised this issue at wordpress support forum and received this answer (my translation to English)

a part of the content is requested by https but delivered in http.
Most important is to ensure a consistent delivery of data. So browsers will not block the insecure content

Any ideas about that? Is it a caddy related issue?

I wonder now if it makes sense to run the worpress page without https but /wp-admin with …
But to be honest I would not know how to setup this in my Caddyfile?

To test this, I set up a HTTPS reverse-proxy to a brand new WordPress + MariaDB instance.

docker-compose.yml
version: '3'

services:
  db:
    image: mariadb:latest
    environment:
      MYSQL_ROOT_PASSWORD: [snip]
    volumes:
      - ./db:/var/lib/mysql
    restart: always

  wordpress:
    image: wordpress:php7.0
    depends_on:
      - db
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_PASSWORD: [snip]
    networks:
      default:
      frontend:
    volumes:
      - ./wp:/var/www/html
    restart: always

networks:
  frontend:
    external:
      name: cadmus_default

After composing up, I visited the site via HTTPS.

Request log
traefik_1 | [snip] - - [02/Nov/2017:00:30:51 +0000] "GET / HTTP/2.0" 302 0 - "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0" 102 "Host-wp-cadmus-whitestrake-net" "http://172.18.0.11:80" 11ms
traefik_1 | [snip] - - [02/Nov/2017:00:30:51 +0000] "GET /wp-admin/install.php HTTP/2.0" 200 3866 - "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0" 103 "Host-wp-cadmus-whitestrake-net" "http://172.18.0.11:80" 905ms
traefik_1 | [snip] - - [02/Nov/2017:00:30:52 +0000] "GET /wp-includes/css/buttons.min.css?ver=4.8.3 HTTP/2.0" 200 1550 "https://wp.cadmus.whitestrake.net/wp-admin/install.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0" 104 "Host-wp-cadmus-whitestrake-net" "http://172.18.0.11:80" 1ms
traefik_1 | [snip] - - [02/Nov/2017:00:30:52 +0000] "GET /wp-admin/css/install.min.css?ver=4.8.3 HTTP/2.0" 200 1991 "https://wp.cadmus.whitestrake.net/wp-admin/install.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0" 105 "Host-wp-cadmus-whitestrake-net" "http://172.18.0.11:80" 1ms
traefik_1 | [snip] - - [02/Nov/2017:00:30:52 +0000] "GET /wp-includes/css/dashicons.min.css?ver=4.8.3 HTTP/2.0" 200 28612 "https://wp.cadmus.whitestrake.net/wp-admin/install.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0" 106 "Host-wp-cadmus-whitestrake-net" "http://172.18.0.11:80" 4ms
traefik_1 | [snip] - - [02/Nov/2017:00:30:52 +0000] "GET /wp-includes/js/jquery/jquery-migrate.min.js?ver=1.4.1 HTTP/2.0" 200 4014 "https://wp.cadmus.whitestrake.net/wp-admin/install.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0" 108 "Host-wp-cadmus-whitestrake-net" "http://172.18.0.11:80" 1ms
traefik_1 | [snip] - - [02/Nov/2017:00:30:52 +0000] "GET /wp-admin/js/language-chooser.min.js?ver=4.8.3 HTTP/2.0" 200 240 "https://wp.cadmus.whitestrake.net/wp-admin/install.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0" 109 "Host-wp-cadmus-whitestrake-net" "http://172.18.0.11:80" 0ms
traefik_1 | [snip] - - [02/Nov/2017:00:30:52 +0000] "GET /wp-includes/js/jquery/jquery.js?ver=1.12.4 HTTP/2.0" 200 33766 "https://wp.cadmus.whitestrake.net/wp-admin/install.php" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0" 107 "Host-wp-cadmus-whitestrake-net" "http://172.18.0.11:80" 7ms
traefik_1 | [snip] - - [02/Nov/2017:00:30:53 +0000] "GET /wp-admin/images/wordpress-logo.svg?ver=20131107 HTTP/2.0" 200 1521 "https://wp.cadmus.whitestrake.net/wp-admin/css/install.min.css?ver=4.8.3" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0" 110 "Host-wp-cadmus-whitestrake-net" "http://172.18.0.11:80" 1ms
traefik_1 | [snip] - - [02/Nov/2017:00:30:53 +0000] "GET /wp-admin/images/spinner-2x.gif HTTP/2.0" 200 8536 "https://wp.cadmus.whitestrake.net/wp-admin/css/install.min.css?ver=4.8.3" "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0" 111 "Host-wp-cadmus-whitestrake-net" "http://172.18.0.11:80" 1ms
traefik_1 | [snip] - - [02/Nov/2017:00:30:54 +0000] "GET /wp-admin/css/install.min.css?ver=4.8.3 HTTP/2.0" 200 1991 - "Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:57.0) Gecko/20100101 Firefox/57.0" 112 "Host-wp-cadmus-whitestrake-net" "http://172.18.0.11:80" 1ms

The logs show a number of extra requests your browser should be making, including for /wp-admin/css/install.min.css?ver=4.8.3. Things like the SVG logo and loading spinner are specified in the stylesheet, so they’re missing too.

Your Caddy log indicates it’s not even receiving requests for that stylesheet, so you need to troubleshoot your browser to find out why it’s not proceeding past the original document.

It’s not a mixed content issue and Caddy can’t do anything if your browser isn’t making the request in the first place.

Maybe you can try it broehlis.my-wan.de with your browser setup.

Thanks

Unlike the first-time setup page, the main WordPress application likes to link to things directly, including the scheme and host it thinks it’s serving from.

WordPress can get pretty funny about just up and moving to HTTPS. If you haven’t configured it very far yet, I suggest reinstalling it, but doing the first-time setup over HTTPS.

Otherwise, you can grab one of the large number of insecure content fixer plugins. They’ll rewrite your HTTP link tags to HTTPS, which will fix the problem.

The WP setup which you visited was done via https address and caddy settings.
I am really at the end of my knowledge. Later I will try to generate a container with your composer file …

That’s really odd, I’m not sure how to explain the discrepancy. If it was set up over HTTPS, configured with a HTTPS website address, same container, pretty much the same Caddyfile…

You’ll need to adapt my compose file because my networking assumes WordPress is in one Docker network with Caddy and connected via another Docker network to the database. You could compose Caddy in the same project, and remove all network keys. Alternately you could add a ports key to open WordPress up to a port on localhost and proxy from Caddy to that… There’s a few ways you could go about it.

My idea would have been to just use wp part and use exiting mariadb with new db

OMG,

I guess I found the bug. All my containers which are using mariadb are normally not linked to it (–link …) and it is working.
I wonder if each webapp should have a dedicated mysql-container??

This is what I now changed. I added a own mariadb container just for WP and linked it to the WP-container. Now it is working …

Thanks to all of you for your help and your patience!

Well, you definitely can use the same mysql container for multiple applications as long as they use separate databases.

With the way containers work, though - for backup, portability, security, etc. - I find it far simpler and easier to have each application have the root password of its own individual database.

Awesome, glad it’s worked out!

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.