Allow env vars to control wp-config.php settings

[RobjS]

This PR makes all the settings in the wp-config.php file controllable by env vars. The hardcoded settings have caused us issues in the past, because they mean that e.g. it's not possible to run a wpc-based WordPress instance that can be pointed at two different database instances (e.g. to switch between a development and a test db). This means we end up having to wrangle a single database to switch between test and development data, e.g. by backing up dev data before running a test suite, and then having to restore that backup once the tests are complete.

By making all the settings over-ridable by env vars, it's easy to point a WordPress container at different database instances, or even to run two different WordPress instances side-by-side on different ports, with each pointing at a different db.

I wouldn't expect us to to ever need to over-ride a lot of the settings in the file, but it was simple to extend the approach to every variable in wp-config.php, so that's what I've done.

How to test

1. Pull this branch, and build a local copy of this image:

   cd images/wordpress
   docker build -t local/test-wordpress-image .
   

2. Pick an example Whippet project (ideally one you already have a db set up for locally, but any of our docker-based WordPress projects will work), and in the docker-compose.yml file replace image: thedxw/wpc-wordpress with image:local/test-wordpress-image. When you run docker-compose up, the site should start up as normal.

3. Now add a second MySQL container to the docker-compose.yml file, as follows:

   mysql_test:
     image: mariadb:10
     ports:
       - "3308:3306"
     volumes:
       - mysql_test_data:/var/lib/mysql
     environment:
       MYSQL_DATABASE: wordpress
       MYSQL_ROOT_PASSWORD: foobar
   

4. Add the following to the end of the wordpress image in the docker-compose.yml:

   environment:
      - DB_HOST=${DB_HOST}
   

5. Add mysql_test_data: to the list of volumes at the top of docker-compose.yml.

6. Stop your existing docker containers, and then start the network again with DB_HOST=mysql_test docker compose up. When you visit http://localhost, you should find you're at the start of a fresh WordPress install process. Complete the process and setup a basic site.

7. Now stop the containers and re-start them in their original state, using DB_HOST=mysql docker compose up. You should find you're now viewing your original dev site. You can now switch between them by stopping and re-starting the network with the appropriate DB_HOST variable, and the unique data for both should persist across docker stop/starts.

[snim2]

This sounds like it could be useful for dxw-extras?

[snim2]

This works for me locally.

Just as an aside, the Beanstalk Console image is no longer on Docker Hub, so will need to be deleted from the docker-compose YAMLs at some point.

[RobjS]

This sounds like it could be useful for dxw-extras?

Yes, it'll hopefully be useful for any project where we want to reset a site into a known state to run acceptance tests. This change was partly prompted by our discussion yesterday about making more use of plugins for custom functionality, and thinking about how writing acceptance tests for a plugin that does one discrete thing should be easier than writing an acceptance test suite for a theme that wraps up dozens of pieces of custom functionality.