Extending a custom framework built into WordPress to automatically turn the 'Search Engine Visibility' setting ON / OFF, dependant on environment

Question

I have a WordPress framework that I am currently working in, it is a thing of beauty, however it is not what I am used to. I am attempting to extend this framework to automatically turn the toggle (found here: Dashboard -> Settings -> Reading -> Search engine visibility) ON or OFF dependant on the environment (Local / Develop / Staging / Live).

I have .env files set up that contain different parts of the settings for that environment, and that environment only. These .env files are called in after there are base settings made to the config.

An example is like so:

<?php
use Roots\WPConfig\Config;

/**
 * Debugging Settings
 */
Config::define('WP_DEBUG_DISPLAY', false);
Config::define('WP_DEBUG_LOG', env('WP_DEBUG_LOG') ?? false);
Config::define('SCRIPT_DEBUG', false);
ini_set('display_errors', '0');

/**
 * Pull in relevant .env file
 */
Code to pull in .env file.

Then within an .env file we are looking like this:

<?php
/**
 * Configuration overrides for WP_ENV === 'local'
 */

use Roots\WPConfig\Config;

Config::define('SAVEQUERIES', true);
Config::define('WP_DEBUG', true);
Config::define('WP_DEBUG_DISPLAY', true);
Config::define('WP_DISABLE_FATAL_ERROR_HANDLER', true);
Config::define('SCRIPT_DEBUG', true);

ini_set('display_errors', '1');

// Enable plugin and theme updates and installation from the admin
Config::define('DISALLOW_FILE_MODS', false);

Its clever, however, now we know how this is happening, I am trying to add in a line that will update the Search engine visibility toggle (found here: Dashboard -> Settings -> Reading -> Search engine visibility).

Can anyone point me towards a complete list of these definable settings (such as define('WP_DEBUG', true)), specifically the Search engine visibility toggle?

For a bonus point, do I need to define 'use Roots\WPConfig\Config' twice; once in the root config and again in the .env specific files?

Any information would be greatly appreciated, happy coding.

EDIT: Following on from Sir Peattie's advice.

I have located this set up in the framework:

if (defined('WP_ENV') && WP_ENV !== 'production' && !is_admin()) {
    add_action('pre_option_blog_public', '__return_zero');
} 

If I then try track 'pre_option_blog_public' elsewhere, it leads nowhere. However, there is results for:

add_action( 'update_option_blog_public', 'update_blog_public', 10, 2 );

And also:

add_action( 'update_blog_public', 'wp_update_blog_public_option_on_site_update', 1, 2 );

Which leads me towards:

/**
 * Update this blog's 'public' setting in the global blogs table.
 *
 * Public blogs have a setting of 1, private blogs are 0.
 *
 * @since MU (3.0.0)
 *
 * @param int $old_value
 * @param int $value     The new public value
 */
function update_blog_public( $old_value, $value ) {
    update_blog_status( get_current_blog_id(), 'public', (int) $value );
}

This:

if ( $new_site->public != $old_site->public ) {

    /**
     * Fires after the current blog's 'public' setting is updated.
     *
     * @since MU (3.0.0)
     *
     * @param int    $site_id Site ID.
     * @param string $value   The value of the site status.
     */
    do_action( 'update_blog_public', $site_id, $new_site->public );
}

And lastly this:

/**
 * Updates the `blog_public` option for a given site ID.
 *
 * @since 5.1.0
 *
 * @param int    $site_id Site ID.
 * @param string $public  The value of the site status.
 */
function wp_update_blog_public_option_on_site_update( $site_id, $public ) {

    // Bail if the site's database tables do not exist (yet).
    if ( ! wp_is_site_initialized( $site_id ) ) {
        return;
    }

    update_blog_option( $site_id, 'blog_public', $public );
}

Am I right in thinking I just need to adjust the existing code for the first line provided in this edit, to not use:

add_action('pre_option_blog_public', '__return_zero');

But instead the line you graciously provided earlier:

add_filter( 'option_blog_public', '__return_false' );

Thoughts?

Answer 1

Those "definable settings" are constants. WordPress defines its default constants in this file. If a constant definition is wrapped in a defined() check, like this:

if ( ! defined( 'WP_DEBUG_DISPLAY' ) ) {
    define( 'WP_DEBUG_DISPLAY', true );
}

Then it means you can define it first in the wp-config.php file (or, apparently, this framework's config files).

The "Search engine visibility" setting does not have a constant you can define from wp-config.php. It's a setting that's saved in the database. You can filter the results of checks to this setting like this:

add_filter( 'option_blog_public', '__return_false' );

This would likely not work in these config files though, as the add_filter() function will not be defined yet.

There's no reason that a framework could not use a companion plugin to allow you to define this with a constant, but whether nor not that is possible is something you will need to as the framework author.

For a bonus point, do I need to define 'use Roots\WPConfig\Config' twice; once in the root config and again in the .env specific files?

Yes, you do. use statements are per-file.

---

To address your update:

I have located this set up in the framework:

if (defined('WP_ENV') && WP_ENV !== 'production' && !is_admin()) {
    add_action('pre_option_blog_public', '__return_zero');
}

... Am I right in thinking I just need to adjust the existing code for the first line provided...

No, your suggestion is not correct. Or, at least there's a much better way.

The add_action() in your edit is, for all intents and purposes, the same as what I gave you. The important part is that the framework will apply this for you if WP_ENV is not 'production'.

I found this in the documentation of your framework: https://roots.io/docs/bedrock/master/environment-variables/#wp-env