Feature/v3

[simonrjones]

Support for WordPress native WP_ENVIRONMENT_TYPE, this requires some breaking changes so I've created a new major release and updated docs accordingly. See issue #37

[simonrjones]

@gtrinkwon @sean-dunwoody Can I have your advice on possible options for replacing the local wp-config.local.php file for sensitive settings? With this update I've had to replace this file (since WP counts "local" as a possible environment type so the name now clashes with a possible valid environment config file).

1. Replace with another file, e.g. .wp-config.php (which I've done in this branch)
2. Use the .env file to set any local sensitive settings and auto-populate these into PHP constants. A bit like dotenv but for WordPress (this option seems more aligned to PHP best practises). E.g. WordPress constants could be included in an .env file in the format: DB_PASSWORD="mypassword"

[sean-dunwoody]

Hi @simonrjones ,

Just a few of thoughts from me:

1. Using an .env file feels like the better approach in terms of best-practices etc. And it would be standard compared to most other projects (for us as an agency, but also hopefully for anyone else that uses this)
2. Very occasionally it might be necessary to include logic (e.g. an if statement) in a local PHP file. This is the only drawback I can think to using an .env file. And while this is a very rare occurrence, I do imagine it crops up from time to time
3. While using an .env file feels better in lots of ways, it might feel a little bit muddled having some config in php files, and other config in an .env file

On balance I think it would be best to go for the .env option.

The other route might be to perhaps offer both options, but default to the .env file? Or if that will be messy, we could maybe just use an .env file, and any potential needed logic could probably go in something like wp-config.default.php ?

[gtrinkwon]

For the theoretical custom env-specific PHP we might want to include, we still have the option of putting it inside wp-config.<env>.php instead. We wouldn't put credentials in there but potentially any logic that might be needed.

I agree with Sean .env seems to make sense, though it does feel a bit strange combining what feels like two different config systems. If we use .env it would be nice to have something that doesn't require Symfony / Composer packages and can run out of the box. I assume it would work by simply converting these .env vars into PHP constants (define()) Also I take it we wouldn't be retroactively updating projects with this, so it would be fine to stick to PHP 8+ syntax?

Just to confirm the directory structure:

root

• .env (DB_* vars, S3_* vars, anything else)
• config
  • wp-config.load.php
  • wp-config.default.php
  • wp-config.env.php
  • wp-config.production.php
  • wp-config.staging.php
  • wp-config.development.php
• web
  • (wordpress files)

[simonrjones]

@sean-dunwoody @gtrinkwon thanks for your feedback.

You can still include logic in the environment config files, just not the .env file which would only contain secrets. From what I understand other WP projects use .env files too (Roots) so let's go with it.

@gtrinkwon We cannot really use custom environments with WP since it has a fixed list of environments is now supports which you cannot add to. I guess you're thinking of staging and staging2 type environments? As long as the WP_ENVIRONMENT_TYPE is set to staging for both that will work.

Your directory structure looks right to me, I'll make sure we have that in the docs.

And finally, we'll have to talk about retroactively using this on older projects. Ideally we would, so it's designed to work with PHP 7.4+