WP_DEVELOPMENT_MODE on Local

Support
1

I’ve recently built into the must-use plugin that I run on all my live and local websites setting of the WP_ENVIRONMENT_TYPE appropriately (I check '127.0.0.1' == $_SERVER['SERVER_ADDR'] to sense being on Local, but as a side-note it would be better if Local sites all had something like $_SERVER['LOCAL_SITE'] to explicitly check, much like SpinupWP’s SPINUPWP_SITE and DreamHost’s DH_USER). This works for WP_ENVIRONMENT_TYPE just fine, to make my local sites all local environment. I then use this designation in other parts of my code to, for example, force the discouraging of search engines as needed, force payment gateways to test mode, and so on, so that I don’t have to risk forgetting changing those when in local or staging sites.

But on Locals I also want to set WP_DEVELOPMENT_MODE to all. I have to be defensive and check if these are defined already, and it appears that Local is explicitly defining WP_DEVELOPMENT_MODE to be disabled. Is that intentional? If so, why? Doing so makes it impossible to change this in custom code or the config file.

For both of these it may actually be a good idea to consider adding settings on the sites in the Local GUI to let us explicitly set both from there. But at minimum Local should run sites such that we can define these as we like ourselves.

1 Like
3

Thank you for reaching out @alexclst! Checking with our Dev team on this and will follow up here.

4

Local sets WP_ENVIRONMENT_TYPE to local if it’s not already set, but it does not define WP_DEVELOPMENT_MODE.

I’m able to set a development mode value in wp-config.php:

if ( ! defined( 'WP_DEVELOPMENT_MODE' ) ) {
    define( 'WP_DEVELOPMENT_MODE', 'all' );
}

And that value is reflected both in WP-CLI:

> wp eval "var_dump(wp_get_development_mode());"
phar:///Applications/Local.app/Contents/Resources/extraResources/bin/wp-cli/wp-cli.phar/vendor/wp-cli/eval-command/src/Eval_Command.php(39) : eval()'d code:1:
string(3) "all"

Or in an activated test plugin:

<?php
/**
 * Plugin Name: Plugin Example
 * Version: 0.1.0
 */

add_action('wp_head', function() {
    echo '<!-- WP_DEVELOPMENT_MODE: ' . ( defined( 'WP_DEVELOPMENT_MODE' ) && ! empty( WP_DEVELOPMENT_MODE ) ? WP_DEVELOPMENT_MODE : 'unset' ) . " -->\n";
});

> curl --silent http://testsite.local | grep WP_DEVELOPMENT_MODE
<!-- WP_DEVELOPMENT_MODE: all -->

This works for me as a plugin or must-use plugin.

Perhaps something else is defining WP_DEVELOPMENT_MODE in your environment? It might be worth searching your wp-content directory for that text just in case.

5

Interesting. It works if I put this in the wp-config.php file:

But it does not work in my custom mu-plugin. My plugin has the only cases of the constant in my wp-content directory. The plugin instantiates a class that incapsulates the plugin code (and then instantiates a copy of this class at the bottom of the file in global space), and it is right in the __construct() of that where I run my environment config code:

// environment configuration if no one else has done so
$server_vars = isset( $_SERVER ) ? $_SERVER : false;
if ( array_key_exists( 'SPINUPWP_SITE', $server_vars ) || array_key_exists( 'DH_USER', $server_vars ) || defined( 'WP_CLI' ) ) {
	if ( !defined( 'WP_ENVIRONMENT_TYPE' ) ) {
		define( 'WP_ENVIRONMENT_TYPE', 'production' );
	}
} elseif ( '127.0.0.1' == $server_vars['SERVER_ADDR'] ) {
	if ( !defined( 'WP_ENVIRONMENT_TYPE' ) ) {
		define( 'WP_ENVIRONMENT_TYPE', 'local' );
	}
	if ( !defined( 'WP_DEVELOPMENT_MODE' ) ) {
		define( 'WP_DEVELOPMENT_MODE', 'all' );
	}
	if ( !defined( 'JETPACK_DEV_DEBUG' ) ) {
		define( 'JETPACK_DEV_DEBUG', true );
	}
	if ( !defined( 'JETPACK_STAGING_MODE' ) ) {
		define( 'JETPACK_STAGING_MODE', true );
	}
	if ( !defined( 'WP_DEBUG' ) ) {
		define( 'WP_DEBUG', true );
	}
	if ( !defined( 'WP_DEBUG_LOG' ) ) {
		$php_logs = dirname( $server_vars['DOCUMENT_ROOT'] ) . '/logs/php/';
		define( 'WP_DEBUG_LOG', $php_logs . 'debug.log' );
	}
	if ( !defined( 'WP_DEBUG_DISPLAY' ) ) {
		define( 'WP_DEBUG_DISPLAY', true );
	}
}

I am checking the constant in the admin under the Site Health screeen. Is this screen perhaps just not getting the correct value? Using the CLI as you did I get string(0) "", but that makes sense given my code as it currently is, no.

1 Like
6

@alexclst I suspect your plugin code is trying to set those constants after they’ve been read by the Site Health Info code (in debug_data() here) and after WP-CLI when running eval logic. So this is less about Local and more about WordPress’ “boot process” and order of operations.

I don’t think it will be enough to move your class instantiation to an earlier hook or to the file root — it may still not be early enough because code that needs those env vars could run before hooks fire or plugins load.

To set site constants more dependably, you could move your definitions to wp-config.php (you can still apply the conditional logic there). The earlier you can configure environment variables, the better, and wp-config.php loads very early.

This is also consistent with the guidance on setting constants:

Development mode can be set via the WP_DEVELOPMENT_MODE constant in wp-config.php .
wp_get_development_mode() – Function | Developer.WordPress.org

It doesn’t explicitly say not to set it via a plugin, but the expectation seems to be that it will be set early in wp-config.php.

7

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.