Feature Request: More flexible .env.* chosing

[drzraf]

Feature Request: More flexible .env.* chosing

[fab120]

From my point of view, Bedrock should include by default only one way to load env variables; and it should be as simple and general as possible.

You could load env files by looking at a server variable for example HTTP_HOST (.env.example.org); others may prefer to look at the environment (.env.production), others may have a completely different use case as valid as the previous two.

As you can see, this could scale indefinitely and in the long run it will be impossible to handle every use case.
In addition every piece of code that is added to the default boilerplate must be maintained and tested to avoid breakages between releases.

Probably niche but more elegant than any other solution when it comes to handling multiple databases under the same WP instance.

Handle multiple databases under the same WP instance to me seems like a particular use case where manually editing the boilerplate could make sense. If you think about it also in WP if you want to handle multiple databases under the same instance you must customize the wp-config.php by adding some logic before the database settings section.

[swalkinshaw]

🤔 we could define the concept of an "env loader" and make the current implementation the default one. One issue is still how people could customize it? We could try to open a standard file location for any customized loader (eg: config/env_loader.php). It's a catch 22 because the location of the loader couldn't be set in the .env

On the other hand, this is probably fairly niche (since it hasn't come up in ~8 years+) and since Bedrock is designed as a boilerplate to be edited, I'm tempted to do nothing and the proper solution is to modify the core file.

If you want to open a PR with a proposed solution it would help evaluate it, but no promises on it being merged.

[drzraf]

Probably niche but more elegant than any other solution when it comes to handling multiple databases under the same WP instance. if (file_exists('xxx')) { require('xxx'); } else { /* regular loading */ }  would be fine for me as long as xxx is part of the .gitignore

I know about the designed as a boilerplate to be edited but I don't like this : We always need to update sooner or later and keeping the original .git/ is handy when this happens (and minimally touching upstream files is always a good practice anyway)

[drzraf]

under the same instance you must customize the wp-config.php

No need for this. Just:

• The above tweak to the application.php loader
• One Apache alias regarding the filesystem, eg: Alias /app/uploads /srv/www/foo/web/app/uploads-bis
• ... which goes together with wp option upload_path set to <abspath>/web/app/uploads-bis

The last bit I'm trying to workaround is the custom WP_ENV (let's say db2) I need at config/environments/db2.php.
mu-plugins/disallow-indexing.php is triggered because the environment's name is not called production (even if it's used in production).

The goes down to whether only one environment is dedicated to production or if this is an arbitrary limitation which must be removed (I tend to think so).

At least something like strpos(WP_ENV, "production") === false so that WP_ENV=production-bis wouldn't get indexation inhibited?