#2 Containerized WordPress: General troubleshooting and Migration

The docker compose should work out of the box. However this post should shed some light on common troubleshooting or problems which i encountered while preparing the images

I can’t upload any pictures or download plugins.

Independent of using containers a failed upload almost always means, that  the permissions aren’t set right. The PHP module of the webserver will handle uploads thus it needs the right permissions in the directory. The user under PHP is operating is ww-data:www-data and should be set accordingly. This could be achieved as so:

$ sudo chown -R www-data:www-data wp-content/
$ sudo chmod -R 755 wp-content/

You should know that www-data is just a name and is internally mapped to a UID and GID. This problem occured to me with the PHP-fpm module, where within the container the UID and GID of www-data was mapped to 82 however on my host system the UID and GID were 33. Every time PHP would like to write something within the mounted volume under the ID 82 it got denied from the Host. To treat this issue i changed the respective IDs in the Dockerfile.

Caddy doesn’t work anymore, restarts all the time.

This is a general problem when working with a Caddy container. If you have a domain name and specify it in your Caddyfile without any tls specific configuration, Caddy will automatically generate  a certificate from let’s encrypt for your site. However you are only limited to around 20 certificates per domain per week (see this post). Since containers are stateless every time you run the  Caddy container it will generate a new certificate until you hit the limit. That is also why i would suggest you to persist the certificates by mounting the responsible folders. Certificates are stored in the $HOME directory (/home/.caddy) of the Caddy container which you can again configure by passing an environment variable (CADDYPATH) to bend it to your needs.

Migration

I had another setup taken from medium which provided a solution around Caddy (v0.9), PHP(v5.6) and MySQL(v5.5).

Why PHP 7

PHP 7 is said to provide a performance boost in comparison to PHP 5 (see this article). Since we are working on a very tiny computer we want to take everything we can get. However PHP 7 was not compatible with MySQL 5.5 anymore which is why i automatically needed a newer version of MySQL as well. Since there was no MySQL 7 image for Raspberry Pi I decided to stick with MariaDB (v10.3.17) which can be used as a stand in.

Database migration

There was not much effort while migrating from MySQL 5.5 to MariaDB 10.3.17. I could just reuse the mounted /var/lib/mysql files meaning it was just a matter of changing image sources in the docker-compose receipt(however better be save and prepare a backup). After I run the MariaDB Container for the first time i had to update my database with the following command:

$ docker exec webservice_mariadb_1 sh -c 'exec mysql_upgrade -uroot -p"[myrootpassword]"'

I guess because of the update, the hashed user passwords got all mixed up so that i had to update my WordPress admin password. To do so navigate into your MySQL container and run mysql:

$ docker exec -it webservice_mariadb_1 mysql -u root -p

My configured WordPress database is named blog and the user data is stored inside wp_users. You could reset all your users passwords to a default password “passw0rd” like this:

$ UPDATE blog.wp_users SET user_pass=MD5('passw0rd')

Note that the passwords inside this table are all hashed. For the initial password a MD5 hash is accepted  but will be transformed in a more secure hash by WordPress upon first login (source, 17.11.2019).

<<<#1 Installing WordPress on a Raspberry Pi with docker-compose in under 10 minutes

>>>#3 How to backup WordPress and what to consider