Feature Request: More flexible .env.* chosing

[drzraf]

Terms

• I have read the guidelines for Contributing to Roots Projects
• This request is not a duplicate of an existing issue
• This is not a personal support request that should be posted on the Roots Discourse community

Summary

config/application.php looks for .env assuming only one such file exist (and consequently one database can be connected to that bedrock installation).

Several scenario require more flexible .env choosing. In my team, I replace the loader by:

$prefix = explode('.', $_SERVER['HTTP_HOST'] ?? '')[0] ?? '';
$dotenv = Dotenv\Dotenv::createUnsafeImmutable($root_dir, ['.env.' . $prefix, '.env']);

So that locally, our various projects can be access using a subdomain, eg: site1.localhost.dev would load .env.site1.
Today I found that it was a neat way to get WordPress network up and running in -production while still having one database per instance (something not supported by WP), eg:

$dotenv = Dotenv\Dotenv::createUnsafeImmutable($root_dir, ['.env.' .$_SERVER['HTTP_HOST'] ?? '',  '.env']);
// Loads `.env.example.org / .env.example2.com` according to the hostname.

It works well but I'd prefer to do that without modifying Bedrock core files.
Any chance to get a hook or similar that would allow to customize the .env selection inside a 3rd-party file?

Motivation

Why are we doing this?

To support multiple database per Bedrock installation

What use cases does it support?

Local development, improved WP network setup

What is the expected outcome?

More flexible multi-db setups

Potential conflicts / foreseeable issues

None

Additional Context

No response

[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)

[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.

[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?

[swalkinshaw]

Closing since we aren't likely to add this.