You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The new use of getenv_docker for config entries will always fall back to the default values if the environment value is empty for any reason.
It isn't uncommon to run MySQL locally as root with no password in development and testing scenarios, so this breaks a fair bit of existing implementations.
Wondering if it might make sense to align the default values with the defaults of MySQL/MariaDB for the credentials section? (This would be root as username, and an empty string as password)? Doing so would restore any existing testing setups relying on the WordPress image running on default values.
The text was updated successfully, but these errors were encountered:
Instead of the empty (and thus very insecure) values we had before, we opted in #577 to switch to the defaults used by the upstream installation wizard, but even in test environments, I'd suggest using an appropriately unprivileged user for MySQL with a randomly generated password, even if the password is randomly created once and then committed in the YAML or script harness running the tests.
The new use of
getenv_docker
for config entries will always fall back to the default values if the environment value is empty for any reason.It isn't uncommon to run MySQL locally as
root
with no password in development and testing scenarios, so this breaks a fair bit of existing implementations.Wondering if it might make sense to align the default values with the defaults of MySQL/MariaDB for the credentials section? (This would be
root
as username, and an empty string as password)? Doing so would restore any existing testing setups relying on the WordPress image running on default values.The text was updated successfully, but these errors were encountered: