Ability to define WP_DEBUG and other constants in the wp-config.php

[danielbachhuber]

Some developers would like to change the behavior of their wp-now sites with define( 'WP_DEBUG', true );. Other developers may want to define other constants early.

Related #19, WordPress/wordpress-playground#230

Done is:

• We have some mechanism for developers to define constants early, similar to what they'd historically put in wp-config.php.

[adamziel]

Let’s minimize the amount of new ideas wp-cli introduces. We could just use a wp-config.php found in a plugin directory and the developer could add it to .gitignore

[danielbachhuber]

We can let this soak. I'm not sure magically loading a wp-config.php file that isn't actually the wp-config.php file is the correct approach.

[adamziel]

It could be loaded as an actual wp-config.php file. The alternative is to introduce a new concept, like a cli switch or an autoloaded blueprint. Then we do it again when the next challenge shows, and before we know it we have a huge config file that requires studying documentation.

[wojtekn]

Can we do something like wp-env does and let the user define additional constants in the configuration file?

https://developer.wordpress.org/block-editor/reference-guides/packages/packages-env/#default-wp-config-values

We added support for configuration file in WordPress/wordpress-playground#263 and we already have a mechanism that defines constants in prepended PHP file.

[adamziel]

If you're set on CLI switches and configs then let's use the native Blueprint JSON format for. Blueprints are the main mechanism of customizing Playground.

That would involve:

• Support wp-env config by rewriting it as a Blueprint
• Ditto for CLI switches

Then you get merging and composing the two for free. Also, wp-cli will then support the same Blueprints as the web version, so if I build a PR previewer online then I can reuse it as a local dev env for PRs.

The alternative is to hack something for now and end up building a competing blueprint format in wp-now. It will be a burden and, once it's too much of a hassle, will eventually get refactored as a Blueprint anyway.

[adamziel]

The blueprint step defineWpConfigConsts takes care of that:

defineWpConfigConsts(php, {
    “consts”: {
        "WP_DEBUG": true
    }
})

It can also be used via the JSON API.

[bgrgicak]

As a workaround, I modify the ~/.wp-now/wordpress-versions/latest/wp-config.php file.

We recently updated Playground to support WP_DEBUG, this will also enable debugging in wp-now when we update the Playground package.

[adamziel]

Playground now supports setting wp-config constants via rewriting the config file.

The following Blueprint:

{
    "constants": {
        "WP_DEBUG": false,
        "WP_DEBUG_LOG": true,
        "SAVEQUERIES": true,
        "NEW_CONSTANT": "new constant"
    }
}

Will rewrite the following wp-config.php:

<?php
define('WP_DEBUG', true);
// The third define() argument is also supported:
define('SAVEQUERIES', false, true);

// Expression are wrapped in `if(!defined())` guards
define(true ? 'WP_DEBUG_LOG' : 'WP_DEBUG_LOG', 123);

// Guarded expressions shouldn't be wrapped twice
if(!defined(1 ? 'A' : 'B')) {
    define(1 ? 'A' : 'B', 0);
}

// More advanced expression
define((function() use($x) {
    return [$x, 'a'];
})(), 123);

As follows:

<?php
define('WP_DEBUG_LOG',true);
define('NEW_CONSTANT','new constant');
?><?php
define('WP_DEBUG',false);
// The third define() argument is also supported:
define('SAVEQUERIES',true, true);

// Expression are wrapped in `if(!defined())` guards
if(!defined($const ? 'WP_DEBUG_LOG' : 'WP_DEBUG_LOG')) {
     define($const ? 'WP_DEBUG_LOG' : 'WP_DEBUG_LOG', 123);
}

// Guarded expressions shouldn't be wrapped twice
if(!defined(1 ? 'A' : 'B')) {
    define(1 ? 'A' : 'B', 0);
}

// More advanced expression
if(!defined((function() use($x) {
   return [$x, 'a'];
})())) {
    define((function() use($x) {
        return [$x, 'a'];
    })(), 123);
}

It is still possible to define the constants in PHP runtime instead of rewriting the file by explicitly using the defineWpConfigConst with "method": "define-before-run".

This, I believe, concludes this issue.