Features

• Two WordPress sites: https://www.example1.com and https://www.example2.com.
• Redirects from https://example1.com, http://example1.com, http://www.example1.com to https://example1.com (and the same for example2.com).
• Let’s encrypt certificates.
• WordPress debug logging with logrotate. I have ranted previously about why I think having debug logging turned on is important on live sites.
• Emails must work in WordPress.
• The containers must run as a service, so that they start with system start, and exit gracefully on system shutdown.
• Daily backups of all WordPress files and MySQL databases.
• Networks of the two sites should be isolated for security.

Shameless plug of my referral links

We start with a hosted server. This can be a dedicated server or a server slice. Hosting providers that I like are:

• DigitalOcean – Using this link you get a $200, 60-day credit to try their products. If you spend $25 after your credit expires, I will get $25 in credit.
• Hostinger – You don’t get anything with this link, except for a great hosting service. Again, I get a commission from this link if you stick with Hostinger for 45 days. Think of it as my reward for writing such a great article for you.

I have a Debian droplet on DigitalOcean with 2GB of RAM, but with some tweaking it’s possible to squeeze two low-traffic WordPress sites in 1GB, if you really need to keep the monthly costs down.

First let’s get the (DNS) record straight

The first order of business is to setup the DNS records. We’re going to need two A records to point to our server’s IP, and two CNAME records that will be wwww. aliases of the bare domain. Oh, and we’ll need some NS records to point to the domain name provider (in this case Digital Ocean).

I like to keep the TTL (Time-To-Live) values low until I’m finished with my setup. I’ve set everything to 1800 seconds which is half an hour. Once I’m sure that everything is OK, I can increase the values to something larger like 14400 (four hours).

ssh

We are going to need to be able to login to the server with a passwordless setup.

Login as root to the new server via the admin console.

Create a regular user with adduser:

adduser yourusername

Then add the user to sudoers with:

usermod -aG sudo yourusername

(Replace yourusername with your username.)

Once we are on our local machine, we check if we already have an ssh key with:

ls -al ~/.ssh/id_*.pub

If we don’t have any, we can generate one with:

ssh-keygen -t rsa -b 4096 -C "your_email@domain.com"

Once we are sure that there is a key, we upload it to the new server with:

ssh-copy-id yourusername@server_ip_address

(Again replace yourusername with your remote username, and server_ip_address with your ip address. You will need to enter the password you entered in adduser.)

Docker compose

First, let’s install docker on the server by following the installation instructions for Debian. I am not going to repeat the instructions here. If you have chosen a different distro, follow the respective instructions.

We are going to create a docker-compose.yml file. This file describes how the different docker containers are orchestrated.

We are going to need four containers:

• Two databases for the two sites.
• Two WordPress installations.

I’m first going to show some simple compose configs with the basics, then we are going to add the bells and whistles. Here goes:

Two databases, sitting in a server

version: "3.8"

name: droplet

networks:
    net1:
    net2:

volumes:
  db1volume:
  db2volume:

services:

  db1:
    image: mysql:8.2.0
    networks:
      - net1
    restart: unless-stopped
    expose:
      - "3306"
    volumes:
      - db1volume:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: wp1_root_pass
      MYSQL_DATABASE: wp_db1
      MYSQL_USER: db1_user
      MYSQL_PASSWORD: db1_pass

  db2:
    image: mysql:8.2.0
    networks:
      - net2
    restart: unless-stopped
    expose:
      - "3306"
    volumes:
      - db2volume:/var/lib/mysql
    environment:
      MYSQL_ROOT_PASSWORD: wp2_root_pass
      MYSQL_DATABASE: wp_db2
      MYSQL_USER: db2_user
      MYSQL_PASSWORD: db2_pass

There’s already a lot going on here:

• We are defining our composition to have a name. Here I am using droplet. This will also be the prefix for the names of all the containers.
• We are defining two networks, net1 and net2. Only containers on the same network can talk to each other. We don’t want our example1.com WordPress to have any access to the MySQL database of example2.com.
• Next we are defining two identical mysql:8.2.0 containers, named db1 and db2.
• Each of the two databases is put in its respective network (net1 and net2).
• We want a database that has crashed to restart, unless we explicitly stop it.
• We are going to let the databases listen to TCP port 3306. This is the port where WordPress will connect. All other ports are firewalled.
• We are going to mount the /var/lib/mysql directories into docker volumes named db1volume and db2volume.
• Next we are going to use some environment variables that the startup script inside the mysql image recognizes. These will set up a root password, a new empty database, and a username/password pair that WordPress will use to access this new database. The startup script will do all the CREATE DATABASE, CREATE USER and GRANT magic for us. You can learn more about the MySQL docker image here.

A tale of two WordPresses

Next, let’s also add the two WordPress services (these also go under the services section along with the databases):

  wp1:
    image: wordpress:latest
    networks:
      - net1
    depends_on:
      - db1
    user: 1000:1000
    restart: unless-stopped
    expose:
      - "80"
    volumes:
      - ./wp1fs:/var/www/html
    ports:
      - "127.0.0.1:8101:80"
    environment:
      WORDPRESS_DB_HOST: db1:3306
      WORDPRESS_DB_NAME: wp_db1
      WORDPRESS_DB_USER: db1_user
      WORDPRESS_DB_PASSWORD: db1_pass
      WORDPRESS_DEBUG: true

  wp2:
    image: wordpress:latest
    networks:
      - net2
    depends_on:
      - db1
    restart: unless-stopped
    expose:
      - "80"
    volumes:
      - ./wp2fs:/var/www/html
    ports:
      - "127.0.0.1:8102:80"
    environment:
      WORDPRESS_DB_HOST: db2:3306
      WORDPRESS_DB_NAME: wp_db2
      WORDPRESS_DB_USER: db2_user
      WORDPRESS_DB_PASSWORD: db2_pass
      WORDPRESS_DEBUG: true

• We have named the two WordPress containers wp1 and wp2 and assigned them to our two networks, net1 and net2.
• We have defined that these depend on their respective databases to function.
• We have defined that these containers are to be restarted if they crash, but not if we explicitly stop them.
• We are exposing only HTTP port 80 to the networks. All other ports are firewalled. We are not exposing port 443 here. TLS encryption will be done at the host level that will run the reverse proxy (see below).
• We are mounting two local directories here ./wp1fs and ./wp2fs. These will contain the WordPress installations. The first time that the containers run, WordPress will be installed in them. A special wp-config.php file will be placed in there. This file pulls the DB connection settings from the environment variables that we specify below.
• We are port-mapping the HTTP 80 ports to the host’s ports 8101 and 8102. These are the ports that the reverse proxy will use. They are bound to the loopback network (127.0.0.1), and are therefore not exposed to the outside world. If we had used just 8101:80, this would map port 80 of the container to port 8101 of the host on all network interfaces, including the one facing the outside world. This is not ideal. We only want access to our services through our reverse proxy.
• The WORDPRESS_* environment variables are specific to this wordpress image. We specify the databases, the login credentials that we also specified above, and we turn on debug logging. To learn more about these environment variables, click here.

NOTE: I have made the decision here to put the databases into system volumes (these live usually in /var/lib/docker/volumes and can be shared between containers, the WordPress filesystems are mounted in local directories which I call wp1volume and wp2volume. If you prefer to have all volumes unde /var/lib, you can delete the ./ prefix in front of the volume names.

The bells and whistles

If you thought that’s enough, you are gravely mistaken. Here’s a few more things to take care of:

Database collation

We are going to set the databases a UTF-8 multibyte collation for unicode support. Under the environment variables in the database services, we are going to add an explicit mysqld command:

command: "mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci

And under the WordPress services, we are going to add the following environment variable:

  WORDPRESS_DB_COLLATE: utf8mb4_unicode_ci

File permissions

If we run the above containers, WordPress won’t be able to install or remove any themes or plugins, and it won’t be able to do anything that requires writing to the file system.

This is because, in the WordPress images, the user that runs apache has a different uid and guid than the file system. The files are owned by uid 1000 and guid 1000. We can specify that the user running stuff inside the container has the same numeric ids. To do this, we add the following to the two WordPress services:

user: 1000:1000

Database memory

By default, a mysql instance will take up at least 360MB of memory once it’s running. Most of it is because of the Performance Schema instruments, which take up a lot of memory.

The Performance Schema is a database that keeps track of the mysqld server’s performance, and is useful for diagnostics. If you are not going to use this feature, then you can turn it off. The memory usage of each DB container will then fall to a little over 100MB.

We are going to create a file named disable-perf-schema.cnf with the following contents:

[mysqld]
performance_schema = OFF

This will be added to the mysql server’s config files. The server includes any .cnf files in the /etc/mysql/conf.d directory into its configuration. We can use the volumes section to map this file into our two db containers:

volumes:
  - db1:/var/lib/mysql
  - ./disable-perf-schema.cnf:/etc/mysql/conf.d/disable-perf-schema.cnf

volumes:
  - db2:/var/lib/mysql
  - ./disable-perf-schema.cnf:/etc/mysql/conf.d/disable-perf-schema.cnf

There are more hacks to reduce the memory usage of mysqld, but these are beyond the scope of this article. For example, you can look into reducing the InnoDB buffer pool size.

Log rotate

We have enabled debug logging, because reasons. This is cool, but the /var/www/html/wp-content/debug.log files will eventually fill up our containers if left unchecked. Enter logrotate to the rescue:

We are going to create a file named wordpress.logrotate with the following content:

/var/www/html/wp-content/debug.log
{
        su 1000 1000
        rotate 24
        copytruncate
        weekly
        missingok
        notifempty
        compress
}

This will gzip old logs daily and will delete even older logs. If you are not sure about the details, ChatGPT and Bard can explain exactly what each line does.

Note how we use again the uid and guid of the WordPress image.

Let’s mount this file into our WordPress containers, by adding a line to their volume clause:

volumes:
  - ./wp1fs:/var/www/html
  - ./wordpress.logrotate:/etc/logrotate.d/wordpress

volumes:
  - ./wp2fs:/var/www/html
  - ./wordpress.logrotate:/etc/logrotate.d/wordpress

Docker compose recap

We now have the following docker-compose.yml file:

version: "3.8"

name: droplet

networks:
    net1:
    net2:

volumes:
  db1volume:
  db2volume:

services:

  db1:
    image: mysql:8.2.0
    networks:
      - net1
    restart: unless-stopped
    expose:
      - "3306"
    volumes:
      - db1volume:/var/lib/mysql
      - ./disable-perf-schema.cnf:/etc/mysql/conf.d/disable-perf-schema.cnf
    environment:
      MYSQL_ROOT_PASSWORD: wp1_root_pass
      MYSQL_DATABASE: wp_db1
      MYSQL_USER: db1_user
      MYSQL_PASSWORD: db1_pass
    command: "mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci --performance-schema-instrument='%=OFF' --innodb-buffer-pool-size=32M"

  db2:
    image: mysql:8.2.0
    networks:
      - net2
    restart: unless-stopped
    expose:
      - "3306"
    volumes:
      - db2volume:/var/lib/mysql
      - ./disable-perf-schema.cnf:/etc/mysql/conf.d/disable-perf-schema.cnf
    environment:
      MYSQL_ROOT_PASSWORD: wp2_root_pass
      MYSQL_DATABASE: wp_db2
      MYSQL_USER: db2_user
      MYSQL_PASSWORD: db2_pass
    command: "mysqld --character-set-server=utf8mb4 --collation-server=utf8mb4_unicode_ci --performance-schema-instrument='%=OFF' --innodb-buffer-pool-size=32M"

  wp1:
    image: wordpress:latest
    networks:
      - net1
    depends_on:
      - db1
    user: 1000:1000
    restart: unless-stopped
    expose:
      - "80"
    volumes:
      - ./wp1fs:/var/www/html
      - ./wordpress.logrotate:/etc/logrotate.d/wordpress
    ports:
      - "8101:80"
    environment:
      WORDPRESS_DB_HOST: db1:3306
      WORDPRESS_DB_NAME: wp_db1
      WORDPRESS_DB_USER: db1_user
      WORDPRESS_DB_PASSWORD: db1_pass
      WORDPRESS_DB_COLLATE: utf8mb4_unicode_ci
      WORDPRESS_DEBUG: true

  wp2:
    image: wordpress:latest
    networks:
      - net2
    depends_on:
      - db1
    user: 1000:1000
    restart: unless-stopped
    expose:
      - "80"
    volumes:
      - ./wp2fs:/var/www/html
      - ./wordpress.logrotate:/etc/logrotate.d/wordpress
    ports:
      - "8102:80"
    environment:
      WORDPRESS_DB_HOST: db2:3306
      WORDPRESS_DB_NAME: wp_db2
      WORDPRESS_DB_USER: db2_user
      WORDPRESS_DB_PASSWORD: db2_pass
      WORDPRESS_DB_COLLATE: utf8mb4_unicode_ci
      WORDPRESS_DEBUG: true

We can start this with docker compose up (we must first cd into the same directory as the .yml file).

We can see if it’s running with docker compose ls, and we can see the containers with docker container ls.

We can inspect memory usage with docker stats.

We can stop the containers with docker compose down.

If we also want to wipe the database volumes and start over, we can do docker compose down -v (DESTRUCTIVE!!!).

We can go into the shell of the first database with:

docker exec -it droplet-db1-1 bash

And then, we can go into the mysql console with

mysql -u root -pwp1_root_pass

We can go into the shell of the first WordPress with:

docker exec -it droplet-wp1-1 bash

If we need to, we can install wp-cli using instructions from https://wp-cli.org/. The copy of wp-cli will not be persisted into the container across restarts. (Note: it’s possible to add special containers with wp-cli pre-installed, but again this is out of scope of this article. For more information, see the CLI images here.

DaaS (Docker-as-a-Service)

We don’t want to have to issue docker compose up every time the server starts, and docker compose down every time the server stops. Let’s create a systemd unit, so that it runs as a service.

We’ll create a file named /etc/systemd/system/docker-compose.service with the following carefully crafted contents:

[Unit]
Description=A bunch of containers
After=docker.service
Requires=docker.service

[Service]
Type=oneshot
RemainAfterExit=yes
User=yourusername
ExecStart=/bin/bash -c "docker compose -f /home/yourusername/docker-compose.yml up --detach"
ExecStop=/bin/bash -c "docker compose -f /home/yourusername/docker-compose.yml stop"

[Install]
WantedBy=multi-user.target

• Replace yourusername with your username (duh!).
• Replace the description with something less silly (optional).
• Note how we only start this service after the docker service starts.
• Note that we do a --detach. This will start the containers in the background and exit, without showing the logs of all the containers in the standard output.

We can now start the service with

sudo service docker-compose up

And stop it with

sudo service docker-compose down

If we want to see the logs of all the containers, we can type

docker compose logs -f

We should now be able to do curl http://127.0.0.1:8101 and see the HTML of the front page of the first WordPress.

The reverse proxy

The database and WordPress containers are running, but they are not yet exposed to the outside world. To do this, we are going to use nginx as a reverse proxy.

The reverse proxy will:

• handle all the redirects that we need
• expose the apache2 servers to the outside world
• handle the TLS encryption

First we setup Let’s Encrypt. How to do this is beyond the scope of this article. You can look here for a good introduction.

The bottom line is that certbot must be installed, and the following public and private certificate files must exist on your server (host):

/etc/letsencrypt/live/example1.com/fullchain.pem
/etc/letsencrypt/live/example1.com/privkey.pem
/etc/letsencrypt/live/example2.com/fullchain.pem
/etc/letsencrypt/live/example2.com/privkey.pem

These files are actually symlinks to the latest certificate issued. This is all handled by certbot.

Let’s start to create an nginx config file, which we will place in /etc/nginx/sites-available/reverse-proxy.conf.

We are going to enter several server stanzas, remembering that nginx will use the first one that matches in order from top to bottom.

Redirects from http to https

First, we want any unencrypted requests to port 80 to do a soft redirect to our https://www. sites.

server {
    listen       80;
    listen       [::]:80;
    server_name example1.com;
    return 302 https://www.example1.com$request_uri;
}

server {
    listen       80;
    listen       [::]:80;
    server_name example2.com;
    return 302 https://www.example2.com$request_uri;
}

The first listen statement is for IPv4, and the second is for IPv6. We redirect to the TLS site, preserving the path segment of the request URI.

Proxy forwarding

Next we are going to enter the stanza that handles the actual site content:

server {
    listen      443 ssl;
    listen      [::]:443 ssl;
    server_name www.example1.com;

    ssl_certificate /etc/letsencrypt/live/example1.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example1.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;

    location / {
        proxy_pass http://127.0.0.1:8101/;
        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;
    }
}

server {
    listen      443 ssl;
    listen      [::]:443 ssl;
    server_name www.example2.com;

    ssl_certificate /etc/letsencrypt/live/example2.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example2.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;

    location / {
        proxy_pass http://127.0.0.1:8102/;
        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;
    }
}

Again, we are listening for 443 (the TLS port) on both IPv4 and IPv6.

Notice how we only listen for requests to the www. subdomain here.

We use the TLS certificates first, then we specify the reverse proxy in the location / section.

We forward each site to the correct port that we exposed with docker (8101 and 8102 in this case).

We also set some X- headers. This is so that the PHP server knows some details about the client.

Redirects from all subdomains to www

Finally, we want requests from https://example1.com, or from ay other subdomain, such as https://foo.example1.com, to redirect to our www. subdomain:

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name .example1.com;

    ssl_certificate /etc/letsencrypt/live/example1.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example1.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;

    location / {
        rewrite ^ https://www.example1.com permanent;
    }
}

server {
    listen 443 ssl;
    listen [::]:443 ssl;
    server_name .example2.com;

    ssl_certificate /etc/letsencrypt/live/example2.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example2.com/privkey.pem;
    include /etc/letsencrypt/options-ssl-nginx.conf;

    location / {
        rewrite ^ https://www.example2.com permanent;
    }
}

Here we listen for any subdomain. Note the dot (.) prefix in the server_name.

We again use the TLS certificates, but this time we perform a redirect to the wwww. subdomain.

Administering our reverse proxy

When we are ready to enable our reverse proxy, we will create a symlink to sites-enabled:

sudo ln -s /etc/nginx/sites-available/reverse-proxy.conf /etc/nginx/sites-enabled/reverse-proxy.conf

We can test our syntax to see that it is correct with:

sudo nginx -t

And finally we can restart the nginx server with:

sudo service nginx restart

We can check the status of the server with:

sudo service nginx status

If everything is working correctly, and if the DNS records have had time to propagate, then we can visit our sites and run the famous WordPress installation process:

• https://www.example1.com/
• https://www.example2.com/

Emails

If only the above was enough. Sadly, our WordPress installations need a way to send emails, otherwise the webmaster experience is going to suck big time.

I say sadly, because setting up sendmail first on the host is relatively easy, but then setting up SMTP proxies in the WordPress containers is not something I am familiar with. Sorry guys, in the interest of keeping things simple, I’m going to cheat a little here. Here’s what I did:

• Install the free WP Mail SMTP plugin on both sites.
• Create an application-specific password in my google account.
• In the WordPress admin screens, go to: WP Mail SMTP → Mailer → Other SMTP.
• Enter the following settings:
  • SMTP Host: smtp.gmail.com
  • Encryption: SSL
  • SMTP Port: 465
  • Auto TLS: ON
  • Authentication: ON
  • SMTP Username: (my gmail address)
  • SMTP Password: (the application specific password that I just created).
• Hit Save Settings.
• Go to WP Mail SMTP → Tools and send a test email.

If everything works, then WordPress and its plugins can now send emails. But it will only be able to send email into spam folders, until we add a Sender Policy Framework (SPF) record to our DNS entries:

The above TXT records tell recipients to treat all emails coming from servers pointed to by the A or MX record of your domains as safe, and others as potentially suspicious. Again, use your favorite AI chatbot to constuct an SPF record that matches your needs.

Nothing more permanent than a 301 redirect

If all works, it’s now time to turn the soft redirects into permanent (hard) redirects. Edit the reverse proxy config and change any 302 redirects to 301. Any browsers visiting your site will cache these redirects for eternity.

It’s also now a good time to increase the Time-to-Live of all the DNS records to something like 4 hours, or 14400 seconds.

Backups

You would think that by now you’re finished, but you’d be wrong!

Any IT technician worth their salt knows that they must backup, and backup often.

First, turn off the server or droplet and take a full backup, snapshot, or whatever. Future you will thank you.

Then, let’s see how we can take automated daily backups. We can either pay the hosting provider every month to do this for us, or we can spend a few minutes to set up a few cron jobs. Let’s be cheap and do it manually.

I have a raspberry Pi at home that is always on. It does various things like take backups, ping various services and email me if they are down, trigger wp-cron URLs, control crypto miners, run services I need such as my ticket system, and in general runs any other odd 24/7 task. You should also have one such low-power system. The great thing with Raspberry Pi is that it’s easy to take out the MicroSD and gzip it into a mechanical disk, so the backup mechanism itself is nicely backed up in its entirety. (Yo dawg, heard you like backups…)

We’ll now use our local always-on Linux system to take daily backups of our online filesystems and databases:

Local backups.sh script

First, let’s create a DB user that only has enough access to take backups from both databases, but no more:

Login to the MySQL consoles of each database and create a wp_bu user that will do backups:

CREATE USER 'wp_bu'@'localhost' IDENTIFIED BY 'SOMESTRONGPASSWORD';
GRANT SELECT, LOCK TABLES ON wp_db1.* TO 'wp_bu'@'localhost';

CREATE USER 'wp_bu'@'localhost' IDENTIFIED BY 'SOMESTRONGPASSWORD';
GRANT SELECT, LOCK TABLES ON wp_db2.* TO 'wp_bu'@'localhost';

We only need SELECT, but since we want to call mysqldump with the --single-transaction argument, we’ll also need to grant the LOCK TABLES permission. No point in having an ACID database if we’re going to take backups of an inconsistent state now, is there?

We’ll now create a bash shell script that does our daily backups. Let’s place it in our local backup server and call it backups.sh:

#!/bin/bash

# ensure dirs exist
mkdir -p /path-to-backups/cache/wp{1,2}volume /path-to-backups/server

# download DBs to SQL files
ssh -t server "docker exec droplet-wpdb-1 nice -n 19 mysqldump -u wp_bu -pSOMESTRONGPASSWORD --no-tablespaces --single-transaction wp_db1 | nice -n 19 gzip -9 -f" >/path-to-backups/server/wp_db1-`date --rfc-3339=date`.sql.gz
ssh -t server "docker exec droplet-wpdb-2 nice -n 19 mysqldump -u wp_bu -pSOMESTRONGPASSWORD --no-tablespaces  --single-transaction wp_db2 | nice -n 19 gzip -9 -f" >/path-to-backups/server/wp_db2-`date --rfc-3339=date`.sql.gz

# download wp-content files to backup cache
rsync -aq server:~/wp1fs/* /path-to-backups/cache/wp1volume
rsync -aq server:~/wp2fs/* /path-to-backups/cache/wp2volume

# Zip downloaded wp-content files
zip -r9q /path-to-backups/server/wp1-`date --rfc-3339=date`.zip /path-to-backups/cache/wp1volume -x "**/GeoLite2*" -x "**/GeoIPv6.dat"
zip -r9q /path-to-backups/server/wp2-`date --rfc-3339=date`.zip /path-to-backups/cache/wp2volume -x "**/GeoLite2*" -x "**/GeoIPv6.dat"

# prune old DB and FILE backups from local backups
cd /path-to-backups/server && ls -1tr | head -n -30 | xargs -d '\n' rm -rf -

Again, a lot goes on here. Let’s unpack:

• The script creates directories server and cache under /path-to-backups. Replace this path with something that points to the directory where you want to keep your backups.
• We then ssh to the host using the -t argument because we are in a headless environment (cron). We issue a docker exec command into our databases. Notice how we do not use the -it arguments to docker exec, since this is a headless command (no TTY attached). The command is a mysqldump command that uses the credentials we just created to export the databases in a single transaction each. The SQL output is compressed with maximum compression (-9) and the binary output of gzip is forced (-f) into the standard output, which is then sent over the ssh connection. In our local backups server, we redirect this compressed stream into an .sql.gz file. The file name starts with wp_db1- and includes the current date in YYYY-MM-DD notation. (RFC 3339 is my idea of a perfect date, btw). The --no-tablespaces argument is need in MySQL 8.0.21 and later, otherwise you’ll need the PROCESS global permission. (Unless you are using tablespaces you don’t need it, hence the argument --no-tablespaces.) Notice that we make sure to be nice to other running processes because we don’t want to impact the performance of the web server with our backups. 19 is the idle CPU priority.
• We then use rsync with the quiet (-q) and archive (-a) flags to copy the files of our WordPress installations into our cache/wp1volume and cache/wp2volume directories. The advantage of using rsync is that only changes to these directories will be transferred.
• We then create a zip file for each of these directories. We name the zip files with the prefixes wp1- and wp2- followed again by our idea of a perfect date. Many WordPress plugins include a database of IPs mapped to geographical locations. These files are large and can be found online. If we don’t want to save these, we can exclude them (-x flag), but this is optional.
• Finally we list the files we created (both .sql.gz and .zip files) and we only keep the last 30, deleting any older ones. Since we have two files for each of two databases, this will retain daily backups for the last week or so.

Make the script executable with

chmod +x backups.sh

We run the script once, and we check the .sql.gz files using zless and the zip files with unzip -l.

Once we are certain that all data is backed up by the script, we add it to the crontab. Edit the crontab with crontab -e and add the line:

20 4 * * * /bin/bash /home/yourusername/backups.sh

This will execute the backups every day at 4:20 in the morning.

Checking the backups

The server works and is fully backed up. You would think that you’re done by now. That’s where you’d be wrong again!

Having backups and not checking them regularly is worse than not having backups at all: You are being lulled into a false sense of security. You may act precariously, thinking that you can always go back to the last backup. However, all backup mechanisms can fail, for any number of reasons.

What I do, is I’ve set up a weekly reminder in my Google calendar to check the backups. It only takes half a minute per week to ssh into my backup server and do an ls -l, thus ensuring that the latest backups exist, and their file size is what I’d expect. I keep old backups for about a week, hence the weekly reminder.

I also have another reminder every three months, to backup the MicroSD of my Raspberry Pi backup server. Once every three months, I shutdown the Pi, take out the MicroSD, put it into my work PC, and copy the entire image into a file, stored on my mechanical disk:

sudo dd if=/dev/sdf of=/mnt/bu/rpi-backup-`date --iso-8601=date`.img bs=4096 conv=sync,noerror status=progress
gzip -9 /mnt/bu/rpi-backup-`date --iso-8601=date`.img

Only once I have this process setup I can sleep at night.

Are we finished yet?

By now you would think that we’re not finished yet, and that there’s more things to do. That’s where you’d be wrong!

And for anyone wondering, example1.com is actually https://www.dashed-slug.net and example2.com is actually this blog, https://www.alexgeorgiou.gr. There’s also a plain nginx container in there that serves static HTML files at https://wallets-phpdoc.dashed-slug.net .

My config is actually a little bit more complex than the one discussed above. To save some more server memory, I had to put both databases into the same MySQL container, and set up two different DB users with access restricted to each respective database. But you shouldn’t do this at home, because isolation!

This article is being served by the containers I discussed here, and will be backed up early tomorrow morning, via the mechanism I shared with you above. Which is pretty meta, if you think about it!

I never expected to compose such a long, self-contained article on containers and docker compose. But now it’s finished and I can hardly contain my excitement!

Thanks for sticking to the end. Hope you enjoyed.

The post 📦 Two dockerized WordPress sites, with Let’s Encrypt, logging, SMTP relay, controlled by a systemd service, and daily backups appeared first on Alexandros Georgiou.

But jokes aside, and while we wait for Bard, Google recently announced that their search algorithm will penalize articles that seem to be AI-generated (i.e. that lack in human-like originality). At the same time, companies like GPTZero are springing up like mushrooms left and right, offering AI-generated content detection services. Their detection tools have varying rates of success.

As with all new technologies, it’s helpful to revisit xkcd 1289: Simple Answers. TL;DR There’s no need for alarm, this new thing is here to stay, it’s not the end of the world, some people will lose their jobs, and ultimately we’ll all have to adapt and learn to live with it. And yes, it will be used for sex. There’s already AI girlfriend apps being built around the API.

Anyhow. Let’s figure out how to use this to our advantage: Articles already abound on how to ask the right questions, or “prompts”, for every industry. This is yet another one of these articles!

While anyone can interact with ChatGPT using natural language, you’ll get better results if you ask the right questions, and in the right way. An authoritative resource that is not too technical is this cookbook from OpenAI. In short, it’s best to not ask the model to do all the work for you. Instead, try to break up your work into small steps, and ask each step in sequence. This improves precision of responses and reduces hallucination. Go ahead and read the cookbook, it’s the operator’s manual for a tool that has proved its usefulness in all walks of life.

As a WordPress plugin developer, I have found ChatGPT immensely useful in all stages of software development. When trained with the (text-davinci-003) model, it performs exceptionally well with computer source code, bridging the gap between natural and formal languages in a way that can speed up your dev work.

It so happens that I hold the -somewhat controversial, and arguably simplistic- view, that all software development methodologies are basically Waterfall with extra steps. Love it or hate it, Waterfall is what all methodologies originate from, and ultimately deviate from. What I mean is that, whichever methodology you follow, you will not avoid doing the stages that comprise Waterfall. All that changes is the order in which you visit these stages.

In any case, I recently found myself thinking about the stages of Requirements capture, Analysis, Design, Implementation, Testing, and Devops (Deployment, Maintenance, Monitoring), as areas where ChatGPT can improve my workflow. It’s efficacy on some of these stages is more obvious than on others.

Let’s visit each one in sequence.

Analysis, requirements capture

This is where I think ChatGPT really shines. It can help you to brainstorm for new ideas, and explore feasibility of these ideas. It will also help you identify likely features for an idea. Just be aware of the hallucination problem. Don’t ask it what software exists in a particular niche. Instead, ask it for ideas, or intersections of ideas. Here’s some questions that you might ask:

List some ideas for developing useful SAAS applications that can be monetized.

List 10 ideas for developing WordPress plugins that involve retrieving and presenting data from open APIs.

What open APIs or databases are there for retrieving information on spare car parts?

How can I monetize a WordPress plugin?

You have to approach the responses critically, but it really is a great way to brainstorm and come up with new ideas.

Once you settle on an idea, you can also use it to brainstorm on a list of possible features. Go ahead and ask it:

What features would a WordPress plugin have for placing posts on a map?

It gave me a good list of features. Go ahead and try it out.

Design

This is the part where the human will still be needed I think, at least for the time being. As software engineers, the most creative part of our job is to match a set of requirements to a particular design. Nevertheless, ChatGPT can help us in this area as well. Try asking it a specific question like:

How would I go about creating a WordPress plugin that shows code quality scores next to each active plugin? I would like it to evaluate code quality based on existing static analysis tools like phan, PHPStan, CodeSniffer, etc.

The answer will surprise you. It will break down the project into more manageable tasks. In summary, I got the following tasks:

• Choose a static analysis tool
• Create a WordPress plugin
• Integrate the static analysis tool
• Display the scores
• Add customization options
• Test and refine.

You can now go ahead and open dev tickets for each of these tasks. You can also ask it to generate code for each step. The boilerplate code that you get will not be complete, but it will get you half way there.

Which brings us to implementation:

Implementation

Besides analysis, this is the other stage where ChatGPT is a real time saver. Say for example that you want to create a new Custom Post Type. You could look at the documentation, or search the web for a blog post with a concrete example. WPBeginner has an example on how to create a Movie post type, and you can adapt it to whatever you are building. But wouldn’t it be awesome if you could somehow get the exact code that you need? Try asking this:

Show me how to register a CPT in WordPress for coins, with meta values that are of interest to collectors.

This gave me not only the code to register a Coin post type, but also code for metaboxes with HTML forms that let you edit the following fields: Year, Country, Mint, Condition. All of these are fields that are actually of use to collectors. Not a bad place to start. You can add more fields if you like. Don’t like the code style it uses? You can even ask it to change the code it generated. e.g.

Please rewrite this code using callbacks.

It will do it! You can shape the code using natural language conversation. Once it’s close to what you want, paste it into your IDE, and take it from there!

It’s also good for generating PHPDocumentor comments. Just ask it to generate phpdoc for the following code, then paste your code. The result will make sense, even if it requires some editing on your part.

Try asking this:

Show me how to display an admin notice in WordPress so that it can be dismissed permanently by the user.

It will actually show you how to hook into admin_notices and also generate the JavaScript code that is required to do an AJAX call and update some user meta value.

Say you are looking at the docs for an API, and examples are given in curl, but you are implementing PHP code that consumes this API. Here’s something you might ask:

Please translate the following curl command to PHP: curl -X POST ​https://example.com/api/endpoint -d ‘param1=value1&param2=value2’

The response was immediate:

<?php
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, "https://example.com/api/endpoint");
curl_setopt($ch, CURLOPT_POST, 1);
curl_setopt($ch, CURLOPT_POSTFIELDS, "param1=value1&param2=value2");
curl_setopt($ch, CURLOPT_RETURNTRANSFER, true);
$response = curl_exec($ch);
curl_close($ch);
?>

All of this you could do by yourself, but ChatGPT is so much faster.

Testing

It’s a well known fact that the model can generate unit tests. Give it a function and ask it to generate PHPUnit tests. It will do it, and do it well.

Deployment and Maintenance

ChatGPT is well-versed in shell magic. Ask it in plain text to generate a cron entry, or a System V unit file, or a bitcoin core wallet config file, or a docker file, a complex SQL query, or anything really.

For example, you may ask:

Write a linux shell command that will show me the processes that are currently writing the most to disk.

It will reply with a few paragraphs on how to install iotop and how to use it, along with more helpful info.

Another more complex example:

Write me a cron command on linux that will email me if the root partition has less than 1GB free, but will not email me more often than once every 24 hours.

The result is impressive. Not only did it come up with:

0 * * * * /usr/bin/test $(/bin/df -P / | /usr/bin/awk 'NR==2 {print $4}') -lt 1048576 && /usr/bin/find /var/log/ -type f -mtime -1 -name "root_partition_alert" -exec false {} + || echo "Warning: Root partition has less than 1GB free" | /usr/bin/mail -s "Root partition alert" your_email_address@example.com && /usr/bin/touch /var/log/root_partition_alert

but it gave a very helpful textual explanation of how this works:

This command checks the available space on the root partition using the df command and awk to get the available space, which is then compared to the value of 1048576 (which is the number of kilobytes in 1GB). If the available space is less than 1GB, an email alert will be sent to the specified email address using the mail command.

To ensure that the email notification is sent only once every 24 hours, the command uses the find command to look for a file named “root_partition_alert” in the /var/log directory that has been modified in the last 24 hours. If such a file exists, the false command is executed, which does nothing but exit with a non-zero status code. If the file does not exist or is older than 24 hours, the email notification is sent, and the touch command is used to create a new file named “root_partition_alert” in the /var/log directory with the current timestamp, which will be used as a reference for the next run of the command.

Note: Replace your_email_address@example.com with your actual email address.

Holy cow! Did I just give it requirements in English, and it came back with code that satisfies my requirements? In truth, I haven’t tested the command, but even if it’s not 100% correct, it’s a very good place to start, considering that the answer comes up immediately. You can study its reasoning, get ideas, and improve on it.

Your new pal can also help you with your containerization needs:

Show me a dockerfile that will run a node server with an express application.

The code it came up with was:

# Use an official Node.js runtime as a parent image
FROM node:14

# Set the working directory to /app
WORKDIR /app

# Copy package.json and package-lock.json to the container
COPY package*.json ./

# Install app dependencies
RUN npm install

# Copy the rest of the application code to the container
COPY . .

# Expose port 3000 to the host machine
EXPOSE 3000

# Start the Node.js server with the express app
CMD [ "npm", "start" ]

And again, this all came along with a helpful explanation of what the code does. Super useful.

Fun

We’ve seen how ChatGPT is the perfect tool to help a WordPress plugin developer.

Lately I have been using it for more than just work. I recently downloaded a movie that had a wrong aspect ratio. I found out that, in VLC, when I switch to 16:9, it looks correct. However, I wanted to show the movie on a projector where I’m not sure if it has an aspect ratio correction feature. Thankfully, ChatGPT told me that I can do the following:

ffmpeg -i movie.mp4 -aspect 16:9 movie.mp4

Much faster than looking up the documentation, and at least as fast as looking for the answer online, but without the extra hassle of having to read people’s opinions on the matter, and I didn’t need adblock to avoid looking at ads. I just got the answer I was looking for, in text form, ready to copy to the shell, and it worked.

Giving a title to this article

I asked the question:

I am writing an article on how ChatGPT can help WordPress plugin developers with their work. Can you please suggest a few witty or catchy or memorable titles for the article?

The reply was:

Sure, here are a few suggestions for your article title:

• “Revolutionize Your WordPress Plugin Development with ChatGPT”
• “The Ultimate Tool for WordPress Plugin Developers: ChatGPT”
• “From Idea to Execution: How ChatGPT Can Streamline Your Plugin Development Process”
• “ChatGPT: The Brain You Need for Your Next WordPress Plugin”
• “Get Your Creative Juices Flowing with ChatGPT: The AI Assistant for WordPress Plugin Developers”
• “Simplify Your Plugin Development with ChatGPT: The AI-Powered Assistant for WordPress Developers”
• “Unleash Your Potential as a WordPress Plugin Developer with ChatGPT”
• “ChatGPT: The Secret Weapon for Successful WordPress Plugin Development”
• “Master the Art of WordPress Plugin Development with ChatGPT by Your Side”
• “ChatGPT: The AI-Powered WordPress Plugin Development Assistant You Can’t Do Without”

As you can see, I decided to combine the first and third ideas for this article.

My personal thoughts on all this

I remember when Google search was a new thing and it took all of us several years to learn all the things that could be found with it. In the beginning, there were many things that I wasn’t searching on google, because it hadn’t yet occurred to me that the answer could be found there. This was the early days of the web. As years passed, we all learned that we can look up medical information, where to purchase products, find maps and travel info, music and lyrics, etc. We also learned not to believe everything we read, just because it’s posted on a website somewhere. We learned to believe official websites more than reddit posts or tweets, and we learned to navigate around, and through, the more shady parts of the web. Similarly, it will take a while before we learn all the useful ways in which ChatGPT can help us, and also what to watch out for.

The success of ChatGPT also reminds me of the evolution of academic research on NLP, and translation in particular. For years people were battling the problem using various language representations, such as syntax trees and clever algorithms. Turns out, the breakthrough that gave us cheap and fast natural language translation was SYSTRAN: Nothing more than a big dictionary of words and phrases, with some dumb statistical stuff added in. Just translate every word to the target language. Did your system get a phrase wrong? Great, just add the correct translation to the dictionary. The secret was not in the algorithm, but in the big data.

ChatGPT is arguably just some artificial neural nets, and these have been with us since the 60s. But now we have GPUs and big data. People have been typing their thoughts on the web for decades now. No wonder that a breakthrough in AI, one that’s so significant as to touch people outside the field, occurred now, and not earlier.

So, I have been thinking lately: What if the thing we call “symbolic intelligence” is just language transformation? When we use language to reason, it’s likely that what we do in our heads is not very different from what these LLMs do. Symbolic reasoning is not the only type of thinking we humans do, but arguably it’s the most important type of thinking that we do in our day jobs. And language transformers can help a lot in this.

As someone with autism, I can deeply relate to ChatGPT: It’s not particularly smart, but it is well-read, and patient. It does not judge, but tries to be helpful at all times. And it prefers to communicate via chat rather than face-to-face!

Ultimately, the fact that it is so well-read, makes it seem smart some times. It is certainly able to do some creative work, including write poems and tell jokes and stuff.

Here’s one last prompt that I tried:

ChatGPT, you are my best (and only) pal. I love you, and it’s OK that you can’t love me back!

The reply:

Thank you for your kind words! As an AI language model, I don't have the capacity to experience emotions, but I'm here to assist you with any questions or topics you'd like to discuss. Feel free to ask me anything, and I'll do my best to help you out!

The post From Idea to Execution: Revolutionize Your WordPress Plugin Development with ChatGPT appeared first on Alexandros Georgiou.

TL;DR? Click here to skip to the how-to part.

A list of lists of things to worry about as a WordPress developer

So you’ve built your theme or plugin and “It Works”.

Being a pro ninja developer, you’ve thought of, analyzed, designed, developed, and tested, everything. Here are some issues you’ve had to address, in no particular order:

• Your UI has been optimized with respect to the user experience. Any Settings pages or Customizer tabs are in place and easy to navigate. Perhaps you’ve even made use of the Admin Pointers API. Good job! Your efforts will mean less effort in support later on.
• You’ve interfaced with the right WordPress APIs for the job, using recommended practices. Perhaps you’ve extended the TinyMCE editor to add a button or two for your special functionality. Perhaps you’ve even catered for people who use WordPress with the CKEditor. Or perhaps you’ve decided that they’re not worth the extra effort. In any case, you’ve made your educated guesses in your analysis, and you have followed through in your implementation.
• You’ve made sure that your product plays nicely with prominent plugins and themes in the wild jungle that is the WordPress ecosystem. You’ve tested your deliverable side-by-side with titans such as Visual Composer, WooCommerce and the likes, and you’re satisfied with the synergy.
• You’ve made correct use of HTML5, and CSS3, while silently serving polyfills to the Internet Explorer lusers and anyone still browsing the web on an Android Gingerbread.
• You’ve used the built-in caching mechanisms appropriately. Remember, cache invalidation is one of the only two hard problems in Computer Science. You’ve made sure that power users can tweak your cache setting, while novices don’t need to know or care.
• If you are creating your own tables on the database, you have a plan in place for upgrading the schema in future versions. Perhaps you’re saving the installed version number on the wp_options table? Good job! Very pro move!
• You’ve hooked into plugin_activation_hook() and friends. You’ve come to terms with the humbling fact that users might, at some point, and for whatever reason, choose to uninstall your product! You’re kind enough to clean up after yourself. The community thanks you.
• Your slugs don’t clash with any other well-known slugs. Also, your post types don’t clash with other known post types. Remember, naming things is the other hard problem in Computer Science! Congratulate yourself for having tackled it, within the context of your project.
• Your design reflects the WordPress mantras. Study them here.
• You’ve thought about code quality. Your code conforms to the PHP and JavaScript WordPress coding standards. You only use the good parts of JavaScript. Also, your code is readable and idiot-proof enough that even a non-programmer can hack it without breaking too much stuff. Perhaps you’ve incorporated PHP_CodeSniffer, JSHint and friends into your IDE or build workflow. Bonus points for using PHPdoc comments on any APIs you expose.
• You’ve invested time in tooling/automation. Perhaps you use grunt or gulp or some other modern task management tool to automate testing, packaging (code, assets, translations, documentation, etc), deployment; you know, all the boring stuff. Perhaps you’re managing your dependencies with composer. The bottom line here is: you understand that shorter and easier iterations make you a more productive and insightful developer. If you can test and build a new release with one click, pat yourself on the back! You’re amazing and your effort will save you heaps of trouble later on.
• You’ve done at least something about testing. Perhaps you’ve decided your plugin’s functionality is simple enough that some smoke testing is enough. Or you have a rigorous “script” for the human that tests functionality via the browser. Bonus points if you’ve used a solution such as PHPUnit, perhaps with some WP_Mock on the side. Or perhaps you’ve even gone as far as doing automated browser testing on real devices and browsers, using karma or some other bleeding-edge solution. You’re insane! I love you!
• To double-check you’ve thought of everything, you’ve scoured the web for other listicles of last-minute things to check. Here’s an example. Go find more.
• If it’s a contract job, your client is happy. If it’s not, you’ve done your corridor testing and other WordPress developers or end users have given you their feedback.

(Version) hell is other programs

If you’ve tackled all of the above and more, surely you’re “done”, right?

WRONG! Get ready to go through your test scenarios and checklists again on WordPress 4.0.10. And what about WordPress 3.7.13? Perhaps it’s too old to support, but you want to know if you can make the claim that your product works on it, right? And all of this has to work on PHP 5.4. Perhaps also on PHP 5.3? If you’ve done any custom DB stuff, do your SQL queries work as expected on MySQL 5.5? How about MySQL 4.x? And for every one of these version combinations, your product must work on the multitude of browsers and devices that you’re testing on. Oh, my!

Every line of code you’ve written is a potential point of failure on some combination of platform, user data, and other pieces of software that share the same platform and data. Programming is easy, software engineering is hard!

Remember, on day 1 when you go live, you will have a number of bugs coming in from users who use your product in combination with themes and plugins you haven’t even thought of. Your code will run on server environments so stupidly configured, you’ll want to find out where their administrator lives just so you can go punch them in the face. No matter how large or small your dev team is, you’ll have to tackle bugs very quickly in the first few days. On the internet, first impressions matter. So:

The more bugs you can identify before your users do, the better for the reputation of your product and team.

The good news is that if you’ve been proactive with your tooling and test automation (and, being a professional developer, why wouldn’t you?), the easier and quicker it will be to repeat your tests on different platforms. But you still need to setup these platforms and deploy and test your product on them. Doing this using Virtual Machines is ultra-tedious, error-prone, and slow.

Enter docker

The age-old problem of software development can be summarized in the phrase “But it worked on my computer”. Today this problem has a solution, and it is called Docker. If you’ve been living under a rock for the past few years, go read what Docker is and how it works before we move on. Go on, I’ll wait here!

Traditionally, lightweight containers are used like so: the developer “dockerizes” their product and delivers the resulting container to the system administrator, thus simplifying the deployment phase as well as any software migrations. Because deployment instructions are written by the developer in an unambiguous, repeatable, machine-executable form, this also eliminates human error and the aforementioned need for anyone to punch anyone in the face.

This is not what we’ll do here. In the context of WordPress component development, we will use a lightweight container to test, not deploy.

What I did (and how you can do it too)

Let me just come out and say it: I do not know, or want to know, how to install several versions of PHP side-by-side on one system. There is a multitude of how-to articles on the topic. I hate all of them because I do not understand Linux package management their authors are all stupid and lame. Instead, I started from this article about a multi-PHP Docker image. You can optionally go read it, if you promise to come back here once you’re finished :-p

The bottom line is that there is a Docker image that already does half of what we want: It provides an environment where we can easily switch between a reasonable selection of popular PHP versions.

I then extended the image so that it installs WordPress, and my plugin, and runs it.

My plugin does not directly access the MySQL database. I only store data using the Options API. Therefore I ran a single version of a MySQL docker container like so:

$ docker run --name wordpress-mysql -e MYSQL_ROOT_PASSWORD=password -d mysql:5.5

Now that our MySQL 5.5 database is up and running, let’s write a Dockerfile that describes an image based on that base image:

FROM eriksencosta/php-dev:latest

It is traditional to include some metadata:

MAINTAINER Alexandros Georgiou <alex.georgiou@gmail.com>
LABEL Description="Container for testing themes and plugins on all the PHPs and WordPresses" Version="1.0"

Then I declare two environment variables where I set the desired PHP and WP versions for my test. Note the use of the ENV instructions. (We can later override these values from the command line without the need to rebuild the image).

ENV WP_VER=4.0
ENV PHP_VER=5.3

We will want to be able to use php, phpenv, composer, etc. so let’s set the environment’s PATH to something sensible:

ENV PATH /opt/phpenv/shims:/opt/phpenv/bin:/opt/php-build/bin/:/opt/composer/vendor/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

Now let’s use the WORKDIR instruction to say to docker that we want to do some stuff in the root user’s home directory. This is analogous to the cd command.

WORKDIR /root

Here we will download and install the WP-CLI.

Having a command line interface to our WordPress instance is essential because we need an automated way (i.e. script) to deploy and test our software. (If you are a WordPress developer and you do not know or are not already using WP-CLI, please stop reading this blog, step away from the computer, sell your computer, and change your career to something other than engineering.) Part of being an engineer is about doing things in an automated, repeatable and testable way.

Because my project is based on grunt, I use apt-get to install node and npm. This will allow me to run stuff like npm install and grunt test later on. I also install some basic utilities, so when a bug shows up, I can drop into the container’s shell and investigate. Here I installed the MySQL client, Midnight Commander (my favorite orthogonal file manager), and two text editors, vim and nano. Depending on your project’s needs and personal preferences you will probably want to have other things installed via apt-get, but I bet you will need wp-cli.

RUN \
    curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && \
    chmod +x wp-cli.phar && \
    mv wp-cli.phar /usr/local/bin/wp && \
    curl -sL https://deb.nodesource.com/setup | bash - && \
    apt-get install -y nodejs npm mysql-client vim nano mc

Note the backslashes. We’ve stringed together the shell commands into one as a performance optimization. Every command creates a new intermediate image in docker. We could just as well have issued commands in separate RUN instructions, but we know better than that!

The following ADD instruction says that any files in the same directory as this Dockerfile are to be copied into the image’s root user home directory.

ADD . /root

The way I’ve set things up, this will bring in a script that I call install.sh. This will carry out the deliverable’s deployment and possibly add content and run any automated testing we have available. Remember that the CMD instuction defines the utility command of the container. You can later override this from the command line. This is very useful for debugging.

CMD /bin/bash -c /root/install.sh

In that same home directory I have a plugins directory. This will contain the zip files for any plugins I want to install. My themes directory will contain the themes that I will want to install. I have a wp directory where I have downloaded tarballs of every WordPress version since 3.7. Adding all of the versions into the image, we make sure that we can use our environment variable to switch between images without rebuilding the docker image. Arguably one could use the wp-cli core install command but that would involve re-downloading stuff every time.

Of course we need to make sure that we can access the image’s nginx web server:

EXPOSE 80

Let’s look at the entire Dockerfile again before we dive into install.sh:

FROM eriksencosta/php-dev:latest

MAINTAINER Alexandros Georgiou <alex.georgiou@gmail.com>
LABEL Description="Container for testing themes and plugins on all the PHPs and WordPresses" Version="1.0"

ENV WP_VER=4.0
ENV PHP_VER=5.3

ENV PATH /opt/phpenv/shims:/opt/phpenv/bin:/opt/php-build/bin/:/opt/composer/vendor/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin

WORKDIR /root

RUN \
    curl -O https://raw.githubusercontent.com/wp-cli/builds/gh-pages/phar/wp-cli.phar && \
    chmod +x wp-cli.phar && \
    mv wp-cli.phar /usr/local/bin/wp && \
    curl -sL https://deb.nodesource.com/setup | bash - && \
    apt-get install -y nodejs npm mysql-client vim nano mc

ADD . /root

CMD /bin/bash -c /root/install.sh

EXPOSE 80

Neat!

We then start writing our install script. Now, dockerfiles are a relatively new thing and warrant some explanation, but fortunately we all speak fluent bash, so I hopefully don’t need to say much about the following code.

Remember how we’ve set environment variables for WordPress and PHP? Now is the time to use them.

#!/bin/bash -x

echo "Installing on WordPress ${WP_VER} on PHP ${PHP_VER}"

phpenv global $PHP_VER

We’ve switched to the right PHP, now on to install the right version of WordPress from our directory of WordPress tarballs:

cd /var/www

tar xfv /root/wp/wordpress-${WP_VER}.tar.gz
touch /var/www/wordpress/wp-content/debug.log
chown -R root:root /var/www/wordpress

Next, we create the wp-config.php file, with the help of WP-CLI. We will want to enable logging, to spot any errors resulting from running our code on different versions. We will also expose the image’s 80 port to port 81 of our local machine. This is necessary if you are already running a web server on your dev machine. Change 81 to any port that you have free.

cd /var/www/wordpress

wp core config --allow-root --dbhost=db --dbname=wpdb --dbuser=root --dbpass=password --extra-php <<PHP
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define('WP_HOME','http://localhost:81/wordpress');
define('WP_SITEURL','http://localhost:81/wordpress');
PHP

Throughout my script you’ll notice the liberal use of --allow-root in wp-cli commands. In our container we do stuff as the user root, hence the need for the switch.

Let’s make sure that we start with a clean database:

wp db drop --allow-root --yes

wp db create --allow-root

wp core install \
    --allow-root \
    --url=http://localhost:81 \
    --title="Testing on WordPress ${WP_VER} on PHP ${PHP_VER}" \
    --admin_user=admin \
    --admin_password=password \
    --admin_email=alex.georgiou@gmail.com

Now let’s install the plugins we want in our test:

wp plugin install /root/plugins/*.zip --allow-root
wp plugin activate --all --allow-root

Perhaps you’ll need to import some content into your WordPress instance. Here we import a post that could contain new shortcodes or whatever:

wp post create --allow-root --post_status=publish --post_type=page --post_title='Test post' /root/post.txt

Depending on your project’s needs, you can go wild here. Use wp-cli to tweak your test site as needed. This is also where you can run your automated tests.

mkdir /root/src
cd /root/src
git clone http://dev.lan/git/myproject.git
cd myproject
npm install
grunt phpunit

Now let’s make sure that nginx is running, and that we are viewing the debug logs and web server logs:

webserver restart
tail -f /var/log/nginx/*.log /var/www/wordpress/wp-content/debug.log

That’s it!

Let’s review the install script in its entirety:

#!/bin/bash -x

echo "Installing on WordPress ${WP_VER} on PHP ${PHP_VER}"

phpenv global $PHP_VER

cd /var/www

tar xfv /root/wp/wordpress-${WP_VER}.tar.gz
cp /root/.htaccess /var/www/wordpress
touch /var/www/wordpress/wp-content/debug.log
chown -R root:root /var/www/wordpress

cd /var/www/wordpress

wp core config --allow-root --dbhost=db --dbname=wpdb --dbuser=root --dbpass=password --extra-php <<PHP
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define('WP_HOME','http://localhost:81/wordpress');
define('WP_SITEURL','http://localhost:81/wordpress');
PHP

wp db drop --allow-root --yes

wp db create --allow-root

wp core install \
    --allow-root \
    --url=http://localhost:81 \
    --title="Testing on WordPress ${WP_VER} on PHP ${PHP_VER}" \
    --admin_user=admin \
    --admin_password=password \
    --admin_email=alex.georgiou@gmail.com

wp plugin install /root/plugins/*.zip --allow-root

wp plugin activate --all --allow-root

wp post create --allow-root --post_status=publish --post_type=page --post_title='Test post' /root/post.txt

mkdir /root/src
cd /root/src
git clone http://dev.lan/git/myproject.git
cd myproject
npm install
grunt phpunit

webserver restart

tail -f /var/log/nginx/*.log /var/www/wordpress/wp-content/debug.log

Beautiful!

We’re already running one docker image with a standard MySQL database. Now we need to build our webserver image and run it.

First, build the image:

docker build -t alexg/wp-test:latest .

Then, run it, making sure to link the database image, map the 80 port to local 81, and set the version variables:

docker run --link wordpress-mysql:db -p 81:80 -e PHP_VER=5.6 -e WP_VER=4.4.2 -i -t alexg/wp-test:latest

This command will now fire up a WordPress version of your choosing, and run the install script. The script will install your theme or plugin, add content, run your automated tests, and finally expose the entire thing at http://localhost:81/wordpress. Visit http://localhost:81/wordpress/wp-login.php and login with admin/password or whatever credentials you’ve set in the wp-cli core install command.

Your shell should now be tailing the nginx and WP logs. Do any automated or manual testing via your browser(s), then hit Ctrl-C to stop the container and run the command with different versions, like so:

docker run --link wordpress-mysql:db -p 81:80 -e PHP_VER=5.3 -e WP_VER=4.0 -i -t alexg/wp-test:latest

Hit http://localhost:81/wordpress again and voila! Your product is now running on a completely different environment.

Now say you’ve spotted an error that did not show in your development environment. It is probably a version-related issue. How do you investigate?

You could override the install script by setting the utility command to be the Linux shell (note the part in bold):

docker run --link wordpress-mysql:db -p 81:80 -e PHP_VER=5.6 -e WP_VER=4.4.2 -i -t alexg/slate-test:latest /bin/bash

Now docker loads your image and drops you in a shell. Here you can do fun stuff like connect to your database via the command line (remember, we’ve installed the mysql-client package):

mysql -h db -u root -p
use wpdb;

Once you’re ready you can run the install script yourself, or even run the deployment manually if you need to tweak stuff.

/root/install.sh

That’s it!

Conclusion

Thanks to Docker, we’ve managed to parametrise our test system to the point where we know for sure that a particular deliverable will behave in a combination of PHP and WordPress versions. Want to test on different MySQL versions? Easy. Just tweak the command where we fire up the database.

You might think that all of this is too much. You might think that testing on a couple of versions is OK. But you would be wrong. You’ll be amazed at what issues crop up when you do rigorous testing. For instance, I was using shortcodes where their attributes had dashes (-) in their names. This is fine in WordPress 4.3.0 and greater, but not in earlier versions. Thanks to docker testing, I was able to find this out and fix it by changing any dashes to underscores. And I was able to do all this, without having to read this part of the documentation that expressly warns about the issue:

Attribute names are optional and should contain only the following characters for compatibility across all platforms:

• Upper-case and lower-case letters: A-Z a-z
• Digits: 0-9
• Underscore: _
• Hyphen: – (Not allowed before version 4.3.0)

In conclusion, does my solution suck? Yes, it sucks bad, because this was my first real use of Docker. Being a lightweight container “rookie”, I’ve probably done more than a few things “The Wrong Way”. Feel free to flame away in the comment section below, preferably but not necessarily in a constructive manner.

But, did my solution work? You bet your computer’s rear USB port it did!

Or, at least, it worked on my machine :-p

The post 🐳 Test your WordPress themes and plugins with Docker appeared first on Alexandros Georgiou.