[wp-trac] [WordPress Trac] #22251: Helper function to simplify checking for constants

[WordPress Trac]

#22251: Helper function to simplify checking for constants
----------------------------+-----------------------------
 Reporter:  evansolomon     |       Owner:
     Type:  enhancement     |      Status:  new
 Priority:  normal          |   Milestone:  Future Release
Component:  Bootstrap/Load  |     Version:
 Severity:  normal          |  Resolution:
 Keywords:  dev-feedback    |     Focuses:
----------------------------+-----------------------------
Changes (by jeremyfelt):

 * keywords:  has-patch => dev-feedback


Comment:

 I'd like to figure this out and start moving forward.

 The conversation on this ticket is great and highlights several very
 useable ideas. I don't think it will be too tough for us to determine a
 nice path to start on. Some of the following is re-hash, some is fodder
 for brainstorming.

 I see a few immediate questions that we should answer.

 1. If the getting of config data is handled somewhere else besides
 constants, should an attempt be made to make these immutable or are they
 immutable now only because we've used constants from the start?
 2. If config is immutable, can we dump it properly during unit test tear
 down.
 3. Should some constants remain outside of a common config object?

 It seems there are a handful of possible approaches, here are some summed
 up:

 1. A `$config` property inside `WP` storing configuration key/value pairs.
 2. Mimic the current configuration constants as individual properties
 inside `WP`.
 3. A completely separate `WP_Config` or other class to hold and manage
 configuration.
 4. Provide methods to manipulate config data into `$_ENV`.

 I took a quick peek at a few other libraries and from what my unfamiliar
 eye could tell...

 * Laravel uses `$_ENV` to store configurations provided via array in
 various environment specific config files.
 * CakePHP uses a `Configure` class and a `protected static $_values` with
 setters and getters. Allows for the storage of arbitrary configuration
 outside of core code as well. Limited use of configuration constants.
 * CodeIgniter uses a `CI_Config` class with a `public $config` array.

 I stopped there, more examples are definitely welcome.

 An intriguing pattern seems to be environment specific configuration files
 that are loaded in to populate stored configuration data. However, we're
 pretty tied to the constants currently defined in `wp-config.php`. We'll
 likely need to do something that sets a base configuration based on those
 values and some or all of what `wp_initial_constants()` provides.

 Specific use cases that happen to all be testing related:

 * Manipulating `WP_INSTALLING` during unit tests. #31130.
 * Bring tests for `ms-files` back in from the cold. #30256
 * Switch between multiple configurations during multisite bootstrap
 testing. Without the likes of
 [https://core.trac.wordpress.org/attachment/ticket/27884/27884.diff
 27884.diff].

 I made [https://core.trac.wordpress.org/attachment/ticket/31130/31130.diff
 31130.diff] to explore the use of `wp_defined()` and `wp_define()` as a
 way to get around the `WP_INSTALLING` setting. That patch uses a global
 `$wp_config`, which I don't think is a good final answer.

--
Ticket URL: <https://core.trac.wordpress.org/ticket/22251#comment:24>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform