I took a brief look at better-wp-config and I think it would solve a lot of problems for WP developers who do anything at all more sophisticated than just edit the live production site.
We've also been chatting about incorporating this kind of approach into ClassicPress. I think it would look significantly different if added there as a feature of the core platform, at least in terms of file paths.
Great question. That is a somewhat arbitrary default I chose because it would then group all or at least most of a project's specifics in /wp-content. That said, where it is located it completely configurable in wp-bootstrap.php file that bootstrap file is pretty much the missing link that I found WordPress has. If we accept the need for a bootstrap file in the root that defines environments and configuration location, then configuration can become must more flexible: - See https://github.com/wplib/better-wp-config/blob/master/wp-bootstrap-sample.php#L11 Note that I envision a great place for config would be in the managed webhost's "private" directory: - WPEngine - /_wpe_private - Pantheon - /wp-content/uploads/private
What I created was really a PoC, and ideally in my perfect world it would work with WordPress too w/o requiring core changes. I had to make a lot of arbitrary choices to actually implement a working PoC but for many of those concepts I don't have a strong opinion about how they were implemented, unless doing it a certain way solved a particular problem. So any arbitrary choices could be easily changed if a group of others could recommend a better approach. (edited)
A lot of what I was trying to solve was to come up with something that could be standardized so that all web hosts could potentially use it, but flexible enough that each web host would not have to modify "core" code thus making deployments not only easier but also more portable.
I also wanted it to be really easy to use, and discoverable. For example, add the following to a theme's functions.php file and see what all the options are:
FYI the design uses flat arrays for configuration so they can be easily and quickly merged for cascading defaults. The sections are somewhat arbitrary but something I picked that I felt worked. The section[option] format was chose because .env can support that and not section.option or section:option.
The defaults are there for standardizing them for local development. But the wisdom of that is definitely debatable. Even if we don't it should at least default to null.
I've started using wp config create / wp config set more for setting up / modifying WP instances. I guess we'd have to make a separate tool that does something similar here?
BTW, I have realized there are several other things I think I should do, such as add a config.secrets file, so rather than just implementing I am going to add issues on GitHub so others could discuss them before I barrel ahead anymore.
I guess an alternative directory structure would be a config/ directory at the top level that contains the needed files (and better-wp-config.php would live in the core code, and wp-config.php would be optional).
One of the goals for BWPC was to support any arbitrary directory structure that WP can support. So it is really agnostic to directory structure (and nothing else I have seen before for WP has been agnostic to directory structure, one of my reasons for wanting to implement this..)
Ah, yeah. We are running clients sites who pay for it. I also have a client who uses WPEngine, but that has been so much more hassle than Pantheon. What I like about Pantheon is that a built-in workflow and support for up to 13 environments (clones of the same site) per site which map to Git branches. (edited)
current project, can't use staging for a multisite on WPE because they can have HTTPS basically only on production. Had to manually clean up the DB from a bug I have done by using their sucky phpmyadmin :disappointed:
I basically prefer linode or digital ocean for everything, but I can see how client might be intimidated by having to get someone to do the server admin
We have more "enterprise" clients (mid market really), and they want to have someone to chew out (other than us) if things go very wrong. Hence Pantheon and WPEngine.
I agree with you. I'd rather only a few people were using BWPC for a while to make sure the design/architecture is solid and meets all necessary use-cases.
Since both of you are here, let me throw out a rhetorical question I'm sure you've been asked before or at least contemplated: "Why not merge the C*Press efforts into one?"Looking from the outside you are both tracking so much in parallel. Not need to answer now...
I do not mind, just do not want people to feel like they need to relearn everything when switching between one and the other. Not sure there is any code to add here in addition to Mike's code, but maybe standartization on file locations will be nice
One area of standardization I am really interested in is the hosting community on WordPress core. I have participated there but only lurked lately because it's been all Gutenberg and the time, but once that's dealt with I want to try to get them to work on a common spec. And I think you two would be good to get them to adopt all the same standards our respective efforts are trying to create so it will be easier for them to provide hosting for your forks.
Whereas ClassicPress started out anti-GB, but I think we're going to take it in a direction of "what else could WP have built towards, that would have been worth doing".
The anti-GB message did not appeal to be because I am agnostic about GB, but moving WP forward in a way that Automatic and the core WP team won't appeals to be greatly. Especially if it can be mostly compatible.
Seriously. I am 55. I had a college co-op job working for IBM doing software support on the original IBM PC. (And there is a reason I bring this up...)
And Microsoft released a Windows that could run on DOS. All the techies of the day hated Windows and loved OS/2. All the magazines said OS/2 was the future. (edited)
Problem was, people running PCs had shit to get done, and could not do a "forklift" upgrade, buy all new software, and completely relearn everything, so they started dabbling in Windows because it would let them continue to run DOS on their (then) $5000 PC. (edited)
What I learned, is you have to transition people over time. So early compatibility with what came before is critical to building an ecosystem. Once you have enough of a user base, then you can start to innovate in incompatible ways. Which I think is pretty much what @James Nylen sounds like he wants to do with ClassicPress, over time.
@Mark Kaplun That, btw, was not related to anything you have said or done, I was just wanting to put this out there because one of the few benefits of aging is having actually experienced an instructive history!
@James Nylen@Mark Kaplun A good (rhetorical) question is, do you expect lots of switchers, or would new installs be a more successful recruitment strategy? Even if the new install is rebuilding/replacing an existing site (which a client of mind is doing right now.)
One of the things I am doing is managing a group of about 15 sites on WPEngine for a client where each of the sites has a different business owner and some are very active with me and some I have never spoken to. All the sites appear to have each been built by a different internal person and/or outside agency, and there is no standardization regarding plugins or themes.
my very far frutue goal is to load header.php after the footer :wink: so many problems can be solved that way :slightly_smiling_face: part of my scifi movie
I have found the best strategy is to not touch a site unless I am going to make major changes because there could be too many buried landmines. But it we are updating/replacing a site we can add new plugins in rather than decide to remove plugins that might be needed. If I were looking in from the outside I would feel the same way about ClassicPress and CalmPress. Okay to use on new builds but not okay to use on an existing site unless I got lots of time to debug. #jmtcw
Given the new forks, ClassicPress and CalmPress it makes sense that they might have different defaults. The question would then be, how do we recognize the default? I can envision these as potentia...
