Hi Mike, I do generally like better wp config, actually very aligned with the "scifi" way I was thinking of, I do have some minor problems with the locations of the files which I assume are easily solvable, but the biggest thing that stopped me when I was thinking about array based configuration is backward compatibility.
so much WP documentation instructs you to add that one define in wp-config.php, and most people can do that even if they are not very technical without creating some PHP error.
The focus of my concerns are the project files as the others will most likely be edited by developers and they should know enough to either not break things or be able to recover from breakage. But project is more tricky
Now I looked better at the code and I see that there might be several configuration formats. At the very least one of them should be default, and IMHO for "project it should be the .env format
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.
>"I do have some minor problems with the locations of the files which I assume are easily solvable"
That is fully configurable in wp-bootstrap.php. Just specify a different directory for the config. The structure inside that directory is currently fixed, but Better WP-Config (BWPC) is a proof-of-concept at the moment and open for feedback and potential improvement from others. I had to decide a bunch of things which were arbitrary and we could easily select different approaches for those arbitrary choices.
First argument for .php being the default is that BWPC can work with .php format without anything else being installed. It requires phpdotenv to be installed with Composer to use .env, so that right there is one reason for .php being the default. Ultimately we could roll-our-own .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. Ironically the .env format has limitations compared with the currently default .php format. Take are look at this Pantheon configuration file and consider how you would do this in .env? - https://github.com/wplib/better-wp-config/blob/master/wp-content/config/providers/pantheon.php That Pantheon "provider" in the link above basically duplicates what they Pantheon has as their defaults: - https://github.com/pantheon-systems/WordPress/blob/default/wp-config.php So as I work with 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.
- From https://github.com/vlucas/phpdotenv#usage-notes And on local development you would use non-secrets for DB so no problem in committing those to version control. And even if you did need to use secrets like API keys the problem is the same if you are using .env or .php. Maybe we need to add a config-secrets.php loaded after the environment but before the host which you always .gitignore and never commit to version control? So I'm questioning if the growing consensus that we should all move to .env files for WordPress-ish (X-Press?) implementations considers all the ramifications of said use? At this point I am thinking if people are given the choice of using .envand.php they will fall back to the .php because AFAICT it makes necessary things possible that you can't (easily?) do with .env. So I am coming to believe it has been a collective "Seemed like a good idea at the time" that people will move on from when given the actual option of using it for X-Press sites. But I am more than willing to be proven wrong on this, if I am in fact missing something. I think that what needs to happen is numerous people need to try to use it, both as .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."
One of my focuses in my WordPress work is to get as much as possible into code that can be version controlled instead of in the X-Press database. So if an admin page means putting stuff in the DB, I think that is going the wrong direction. OTOH, WPLib Box/(GearBox) will have admin pages for this kind of thing, and those admin pages will store in files that can be version controlled.
> _"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."
I don't use GitFlow proper so I am unsure of exactly what you are thinking. (We use our own custom developed Git workflow since we found GitFlow did not work for us.) Each named environment could have it's own config file that would get merged in and override the project config file. You would not need to commit that environment configuration file until you are ready to deploy, at which case I assume you'd have to know the credentials, and/or the credentials would come from server-based $_ENV files, in which case it would be a non-issue. Right?
The problem .env solves is separation between configuration and code. I am sure that this is not the only way to solve it, but it does send a message IMHO of **this file should not have any code in it**. This is for the project file which user with little technical background are more likely to have to change. The side benefit is that if you get the syntax wrong you are more likely to be able to get a meaningful error message. The big drawback is that the .env file is much more likely to be exposed to the web, so maybe .php is the only way :disappointed:. Maybe if the format that will be there by default is one of a simple array it will discourage abuse, but than you lose backward compatibility. Oh well, one step at a time. Right now I am not sure what is best, just that the current situation is not great :wink:
What "wordpress" lacks is a way to add code which executes before wp-settings.php is run. This influences the config discussion because right now it is the only obvious place to add such code which will not be removed in an upgrade is wp-config.php. Maybe if people would be encourage to use some other file, it will solve my concerns :slightly_smiling_face:
I can see the separation between config and code can have value. OTOH, I have seen too many use-cases where simply having configuration with no code doesn't meet those use-cases. The main thing what I came up with does it provide cascading configuration so you have defaults at every level, something that define()d constants stop dead in the tracks. And I tried to make the format a non-issue by making that configurable. We could even make is to people could add their own format options, if they really wanted to.
We could easily add a place in BWPC to run early code. One of my goals is to get something that can address all the different use-cases that force people to "customize" wp-config.php so that deployments are easier. (edited)
You know how the W3C does not want to "standardize" anything without actual code that has been running in the wild to prove the concept? Similarly I wanted to get something usable so people could try it and give feedback for what is needed in hopes that we could collectively find "what works," and then make it happen.
As for doing it as part of BWPC, I would be against, mainly because I am a strong believer in code that handles a simple well defined tasks. Once you try to do two tasks as part of one code, at best you get a less maintainable code with inter-dependencies. The question of early code is something that will need to get a buy in from classicpress (or anybody else) regardless of the adoption of BWPC
Like I said, I wanted to create a PoC that addressed all the issues that I have come across, and then hopefully get others to help "firm it up" so that it can actually solve the real world problems that all of us experience in this area.
Well, I do have one opinion. Ideally I would like something that would work with WordPress w/o having to modify core. Which is why I suggested that BWPC could handle it since if it is used then it will be running before wp-settings.php.
Yes, but I realized that was orthogonal to what configuration needed. I'd love to see Calm and Classic doing that, but I doubt WordPress will move anytime soon. I don't think the order changes. It's literally move the call to wp-settings.php from end of wp-config.php to the end of wp-load.php. It's that simple.
BTW, one of the things I was trying to do was not have to change 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.
From my POV, the whole reason for doing calm is that things can be solved in the right way. Too many plugins have more or less success in hacking something that works, but when you decide to fork, you can just do things the right way
I'd be interested to figure out how the "right way" would be different from what I did in BWPC, and then if there are ways for me to support the right way instead or in addition to.
The problem I have found with bootstrapping is no knowing where core or content is located. If I can get those two bits of information, then I can bootstrap. That's where I started when I started working on BWPC.
Yeah. The problem is WordPress designed itself with core in the web root. Had WP designed itself so that core was always in a known subdir then a lot of these problems would not exist. (edited)
If I load config in index.php I can know effectively what ABSPATH is and where to load wp-blog-header.php from w/o having to have the build process potentially modify index.php during a pre-deploy build process.
IF managed WordPress companies allowed us to change their layouts -- companies like WPEngine -- then this would mostly be a non-issue. But we need a Composer-friendly layout for local development and a standard layout at managed hosts.
Thanks to the open source nature of WordPress, anyone – including hackers – can look up the typical file structure of a WordPress website and know exactly where to start an attack. Fortunately, rearranging your core WordPress file structure is one method you can employ from your security arsenal to combat hacks and bolster your site’s defenses. So in this post, I’m going to walk you through two ways you can customize your file structure for single and Multisite installs, as well as show you the code you need to bring it all together.(31 kB)
ok, I do not see right now any hope of deriving any other directory structure base on where the essential files are located. Maybe this is something that can be solved with early.php file. Just need to define well how it can communicate the directory structure (edited)
The approach I took to communicate the directory structure was to allow 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)
ok, the discussion starts to fly over my head, it is past midnight here. I will try to take a look again tomorrow and make sense of the changes done to index.php
