Add a "Platform" config file

[mikeschinkel]

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:

1. Add a define( 'PRESS_PLATFORM', '...' ); at top of index.php and top of wp-config.php. But we want to get away from define()s, so this is going against that, but it might be okay given the context?

2. Assign $_ENV['PRESS_PLATFORM'], $_SERVER['PRESS_PLATFORM'], and/or call putenv('PRESS_PLATFORM','...') at top of index.php and top of wp-config.php.

3. 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):

    <?php
    /**
     * config.platform.php
     */
   
    return array(
    	'environment[platform]'  => 'wordpress',
    //	'environment[platform]'  => 'classicpress',
    //	'environment[platform]'  => 'calmpress',
    );
   

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

[markkap]

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.

[mikeschinkel]

@markkap Hmm. Let me mull over that suggestion for a potential implementation. Thanks.

[nylen]

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.

[mikeschinkel]

@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.)

[mikeschinkel]

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

[nylen]

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.

[mikeschinkel]

@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."

[markkap]

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 ***@***.***> 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 <#3 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABJnml8HhDShBaJZ-6jUhKlmIFLZZ5JDks5uuOqogaJpZM4YP26_> .

[nylen]

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.