> "I do have some minor problems with the locations of the files which I assume are easily solvable"
wp-bootstrap.php. BWPC) is a proof-of-concept at the moment and open for feedback and potential improvement from others. > "IMHO for "project it should be the .env format"
.php being the default is that BWPC can work with .php format without anything else being installed. phpdotenv to be installed with Composer to use .env, so that right there is one reason for .php being the default. .env support and eliminate the dependency but 1.) I think people wanting to use .env will likely be more advanced and thus be Composer users, and 2.) read on as to why I am skeptical about .env actually being a better solution than .php..env format has limitations compared with the currently default .php format. .env?BWPC and web hosts like Pantheon that already use $_ENV for DB credentials the .env format seems to be redundant and thus solving a non-problem except on local development (and maybe shared hosting?), but VLucas says (emphasis mine): (edited)> "phpdotenv is made for development environments, and generally should not be used in production. .env or .php.config-secrets.php loaded after the environment but before the host which you always .gitignore and never commit to version control?.env files for WordPress-ish (X-Press?) implementations considers all the ramifications of said use? .env and .php they will fall back to the .php because AFAICT it makes necessary things possible that you can't (easily?) do with .env. So .env and as .php before we can make a final decision on which is the preferred default. (edited)> "Maybe it would be a good idea to just stop people from modifying the files direct and instead provide some admin page for that."
> _"Something else that popped into my mind, how would the GIT flow be with such configuration? You are going to want the DB credentials in GIT if your deployment plan is based on git pull, but for shared hosting you can not know them in development time."
$_ENV files, in which case it would be a non-issue. Right?define()d constants stop dead in the tracks. wp-config.php so that deployments are easier. (edited)wp-settings.php from end of wp-config.php to the end of wp-load.php. index.php on deployment because I use a different directory layout locally for Composer and then have to deploy to WPEngine and Pantheon to the standard layouts.index.php? require_once() instead. wp-bootstrap identify a configuration file, which could be located in a directory wherever you want, and then I defined the structure in a combination of the values from the config and some hardcoded relative directories, e.g. wp-includes and wp-admins. (edited)