[wp-trac] [WordPress Trac] #41710: optionally obtain WP_* configuration constants from the environment

[WordPress Trac]

#41710: optionally obtain WP_* configuration constants from the environment
------------------------------+-----------------------------
 Reporter:  drzraf            |      Owner:
     Type:  enhancement       |     Status:  new
 Priority:  normal            |  Milestone:  Awaiting Review
Component:  Build/Test Tools  |    Version:  4.8.1
 Severity:  normal            |   Keywords:
  Focuses:                    |
------------------------------+-----------------------------
 Although hardcoding strings inside a configuration is the traditional way
 to setup applications, having smooth configurations values is sometimes
 needed.

 The context of rising CI/virtualization/automated WP deployments increases
 the need of '''provisioning''' WP configuration (setup and adjunst DB
 credentials/debug-mode/site-url/...  in an easy and flexible manner).


 wp-config.php currently imposes harcoding string values in a PHP-formatted
 regular text file. No file override, no override of the source of the
 values.

 This creates [https://github.com/docker-library/wordpress/blob/master
 /docker-entrypoint.sh#L110 coding] [https://github.com/wp-cli/scaffold-
 command/blob/master/templates/install-wp-tests.sh#L111 horrors] where
 people almost invent sed/awk-based PHP macro templating systems to simply
 configure a WP instance.



 The fact that wp-config.php uses PHP-format rather than ini/yaml is
 '''not''' the issue.
 The issue is that the current configuration does not offer the possibility
 of environment indirection.
 (the other "issue" being that developers are reluctant to create a
 modified copy of wp-config-sample.php {{{getenv()}}}-based, maybe to be
 future-proof in case of wp-config.php changes, maybe to respect user-
 provided changes)


 In the Unix world, environment has been the traditional and flexible way
 to transmit information to child processes.


 Is there any blocking wp-config.php from fetching some or all of its user-
 defined constants from the environment out of the box?
 Would maintainers consider such an enhancement?


 Some suggestions (among many possible others):
 1. fetch from {{{getenv()}}} if {{{wp-config.php}}} is absent
 2. fetch from {{{getenv()}}} if mandatory values of {{{wp-config.php}}}
 values are empty
 3. fetch from {{{getenv()}}} even if {{{wp-config.php}}} values are empty
 4. load {{{wp-config.$HOSTNAME.php}}} if present
 5. load {{{wp-config.{PHP_SAPI}.php}}} if present
 6. provide (and maintain) a {{{wp-config-env-sample.php}}}
 {{{getenv()}}}-based
 7. ...


 [https://wordpress.org/support/topic/implement-env-variables-for-wp-
 config/ related forum post]

--
Ticket URL: <https://core.trac.wordpress.org/ticket/41710>
WordPress Trac <https://core.trac.wordpress.org/>
WordPress publishing platform