Open mikeschinkel opened 6 years ago
The way I see it calmPress is going to end with two types of distributions, one with the "classical" directory structure and one which is composer friendly. 3 sounds like the most flexible for such a thing as it is possible to just distribute a different one based on the containing distribution.
But alternatively I would be happy to just pass whatever file can be used for defaults as a parameter to the bootstrap constructor (or by any other way). We can even agree on some naming scheme to avoid collisions if that is needed.
@markkap Hmm. Let me mull over that suggestion for a potential implementation. Thanks.
I am still thinking that as much of better-wp-config as possible should be incorporated into ClassicPress, to make it a first-class option that is very simple to use.
In this context, you just have to pick a different file (or set of files) to edit instead of wp-config.php, and any defaults that ClassicPress supplies would be baked into the code already.
So I don't think having platform-specific defaults should be necessary at all, basically.
@nylen My thinking along these lines is that hopefully BWPC
could be seamlessly included in ClassicPress just like how Requests, SimplePie, getID3(), kses and others are already included in WordPress core.
In this scenario ClassisPress core would provide the platform specifics but the ClassicPress user/developer perspective would not need to even be aware of this, unless of course they dive into the ClassicPress source code.
As I told @markkap on our Slack this weekend (just mentally replace "CalmPress" with "ClassicPress" when you read this):
"Speaking of CalmPress using
BWPC
w/o modification, I will happily commit to not breaking CalmPress and not making a decision that saddles CalmPress with supporting something you want to get rid of, as long as you are okay with enhancements being ones you can change and/or optional that you need not enable, as applicable. My goal is to create something that can become defacto-stardard across all the "X-Press" family."
Clearly it is up to you and the ClassicPress community exactly how you approach this, but I am hoping that having BWPC
stay version controlled in one place vs. copied and modified incompatibly in many places will be better for all the X-Press family. I don't think there is a competitive value in differentiating on config since it will be easier for web hosts to support a single config standard vs. multiple slightly incompatible approaches. In fact I think it will be a competitive disadvantage to has divergent config solutions.
(Also, as an aside, I have no real reason to want to control this, as long as it can meeting my needs which it already does. The lack of a solution causes me problems in other areas and I just want a viable solution to exist and thrive. I'll be happy to create a new GitHub org that with a charter that a consortium of parties interested in being good steward managed, if that ever becomes a need. That said I think early on that action was needed before any such collaboration would be likely to happen.)
@nylen Also, I envision ClassicPress would include a copy of BWPC
and then stick pat with it unless or until you are ready to upgrade to a later version.
If BWPC
ever ends up diverging from ClassicPress' goals, you'd just start maintaining and evolving the last version you used and take it in your preferred direction.
That said, my goal would be you would never have a reason to want/need to diverge from our versioned master
branch, so as long as I am leading BWPC
.
Ok, so we already have a place for a config standard to live: https://github.com/corePress
This is the place for collaboration between pieces that ClassicPress and calmPress share.
The what can live there. (How do I configure ClassicPress, calmPress and WordPress for multiple environments? What extra steps do I need to take to make this work on WordPress?)
The how can live in the ClassicPress and calmPress source code, and the code here can be the pieces that you need to drop in for this to work with WordPress.
I am happy for ClassicPress to refine and follow a standard/implementation like that.
@nylen
"Ok, so we already have a place for a config standard to live: https://github.com/corePress"
So, we could potentially move BWPC
there, once it gets a little more mature. That sounds like a solid plan.
_"The what can live at corePress and the how can live in the ClassicPress and calmPress source code,
So are you saying you do not want a standard implementation, but instead want multiple implementations of the same standard, and thus the need for 3rd parties to have to understand and work around the inevitable incompatibilities, ala Internet Explorer and all the other browsers?
Wouldn't it not be better for the how to live at corePress — for BWPC
as well as for anything else shared — unless and until there is actually a need for divergence?
I believe the idea of trying to maintain multiple different implementations of the same standard — especially without the backing of large companies to fund said development and maintenance — will be fraught with peril.
Or said more simply: "There be dragons."
I am happy with having a library as defining a standard by implementing it. It just needs to be flexible enough to be used in different directory structures and for different required settings. At least right now I can not see any reason calm and Classic might want to implement such a thing in different ways.
On Mon, Nov 12, 2018 at 5:27 AM Mike Schinkel notifications@github.com wrote:
@nylen https://github.com/nylen
"Ok, so we already have a place for a config standard to live: https://github.com/corePress https://github.com/corePress"
So, we could potentially move BWPC there, once it gets a little more mature. That sounds like a solid plan.
_"The what can live at corePress and the how can live in the ClassicPress and calmPress source code,
So are you saying you do not want a standard implementation, but instead want multiple implementations of the same standard, and thus the need for 3rd parties to have to understand and work around the inevitable incompatibilities, ala Internet Explorer and all the other browsers?
Wouldn't it not be better for the how to live at corePress — for BWPC as well as for anything else shared — unless and until there is actually a need for divergence?
I believe the idea of trying to maintain multiple different implementations of the same standard — especially without the backing of large companies to fund said development and maintenance — will be fraught with peril.
Or said more simply: "There be dragons."
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/wplib/better-wp-config/issues/3#issuecomment-437741388, or mute the thread https://github.com/notifications/unsubscribe-auth/ABJnml8HhDShBaJZ-6jUhKlmIFLZZ5JDks5uuOqogaJpZM4YP26_ .
Wouldn't it not be better for the how to live at corePress — for
BWPC
as well as for anything else shared — unless and until there is actually a need for divergence?
Sure, maybe so. I guess I was thinking this would make it more difficult to fit BWPC
into individual projects, but I don't have a strong opinion there.
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 potential approaches:
Add a
define( 'PRESS_PLATFORM', '...' );
at top ofindex.php
and top ofwp-config.php
. But we want to get away fromdefine()
s, so this is going against that, but it might be okay given the context?Assign
$_ENV['PRESS_PLATFORM']
,$_SERVER['PRESS_PLATFORM']
, and/or callputenv('PRESS_PLATFORM','...')
at top ofindex.php
and top ofwp-config.php
.Just load
config.platform.php
and let the platform define itself and don't worry about having different names (but that will make it harder to include multiple samples in our own repo):Some other approach that has not occurred to me?
NOTE: In the short term I have actually committed option #3 but want to hear the opinions of @nylen from ClassicPress and @markkap from CalmPress before finalizing on a solution.