I'm actually -1 on this change -- encouraging/enabling users to use the MySQL root user or an empty password was a mistake IMO (for the same reasons as having this container opportunistically create the database -- the database user given really shouldn't have that level of privileged access 😬), and minor positive breaking changes like this are why we had this newer functionality available for users to pre-test for several months before we enabled it (and even waited for a new release of WordPress itself to do so). 😕

Additionally, for this file to even be used they'd have to be setting some WORDPRESS_... variables (otherwise we don't copy it so that the interactive wizard still works), and IMO asking them to set a few more explicitly isn't unreasonable.

I suppose one improvement we arguably should make is to update our getenv wrapper to differentiate unset environment variables from empty such that the (discouraged!!) configuration is at least possible? (#574)

That sounds reasonable; should we at least restore WORDPRESS_DB_NAME to default to wordpress? If we keep the new default, then someone is going to assume that they can rely on it and set just MYSQL_DATABASE=database_name_here on MySQL. 😬

Hmmmm, good point -- I took these values from wp-config-sample.php, but I'm not sure whether there's much value in that (since the whole point of this is that users can use environment variables instead and thus don't need to edit wp-config.php manually).

Perhaps we should look to the built-in setup wizard and match any default values it pre-fills/suggests?

https://github.com/WordPress/WordPress/blob/fb8c18e54198ad9364213d792ea39b2008d36725/wp-admin/setup-config.php#L218 corroborates wordpress as a default value 👍

(I don't know whether example username and example password as defaults are really any better or worse or indifferent from password_here etc 😄)

(I don't know whether example username and example password as defaults are really any better or worse or indifferent from password_here etc )

If we move to whatever upstream uses as defaults, then we can just point to that in the future (minus localhost for database host, because containers make localhost database very unlikely).

Just tested this stack.yml to work on this new change:

version: '3.1'

services:

  wordpress:
    image: wordpress:test
    restart: always
    ports:
      - 8080:80
    environment:
      WORDPRESS_DB_HOST: db
      WORDPRESS_DB_USER: root
      WORDPRESS_DB_PASSWORD: ''
      WORDPRESS_DB_NAME: exampledb
    volumes:
      - wordpress:/var/www/html

  db:
    image: mysql:5.7
    restart: always
    environment:
      MYSQL_DATABASE: exampledb
      MYSQL_ALLOW_EMPTY_PASSWORD: '1'
    volumes:
      - db:/var/lib/mysql

volumes:
  wordpress:
  db:

Added fix for removing newlines from _FILE contents: #576 (comment)