Extending a customized framework constructed into WordPress to mechanically flip the ‘Search Engine Visibility’ setting ON / OFF, dependant on setting

I’ve a WordPress framework that I’m at the moment working in, it’s a factor of magnificence, nonetheless it isn’t what I’m used to. I’m trying to increase this framework to mechanically flip the toggle (discovered right here: Dashboard -> Settings -> Studying -> Search engine visibility) ON or OFF dependant on the setting (Native / Develop / Staging / Reside).

I’ve .env information arrange that include totally different components of the settings for that setting, and that setting solely. These .env information are referred to as in after there are base settings made to the config.

An instance is like so:

<?php
use RootsWPConfigConfig;

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

/**
 * Pull in related .env file
 */
Code to drag in .env file.

Then inside an .env file we’re wanting like this:

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

use RootsWPConfigConfig;

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

ini_set('display_errors', '1');

// Allow plugin and theme updates and set up from the admin
Config::outline('DISALLOW_FILE_MODS', false);

Its intelligent, nonetheless, now we all know how that is occurring, I’m attempting so as to add in a line that can replace the Search engine visibility toggle (discovered right here: Dashboard -> Settings -> Studying -> Search engine visibility).

Can anybody level me in the direction of an entire listing of those definable settings (akin to outline(‘WP_DEBUG’, true)), particularly the Search engine visibility toggle?

For a bonus level, do I have to outline ‘use RootsWPConfigConfig’ twice; as soon as within the root config and once more within the .env particular information?

Any data could be vastly appreciated, comfortable coding.

EDIT: Following on from Sir Peattie’s recommendation.

I’ve situated this arrange within the framework:

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

If I then strive observe ‘pre_option_blog_public’ elsewhere, it leads nowhere. Nonetheless, there may be outcomes for:

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

And likewise:

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

Which leads me in the direction of:

/**
 * Replace this weblog's 'public' setting within the world blogs desk.
 *
 * Public blogs have a setting of 1, non-public blogs are 0.
 *
 * @since MU (3.0.0)
 *
 * @param int $old_value
 * @param int $worth     The brand new public worth
 */
operate update_blog_public( $old_value, $worth ) {
    update_blog_status( get_current_blog_id(), 'public', (int) $worth );
}

This:

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

    /**
     * Fires after the present weblog's 'public' setting is up to date.
     *
     * @since MU (3.0.0)
     *
     * @param int    $site_id Website ID.
     * @param string $worth   The worth of the location standing.
     */
    do_action( 'update_blog_public', $site_id, $new_site->public );
}

And lastly this:

/**
 * Updates the `blog_public` possibility for a given web site ID.
 *
 * @since 5.1.0
 *
 * @param int    $site_id Website ID.
 * @param string $public  The worth of the location standing.
 */
operate wp_update_blog_public_option_on_site_update( $site_id, $public ) {

    // Bail if the location's database tables don't exist (but).
    if ( ! wp_is_site_initialized( $site_id ) ) {
        return;
    }

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

Am I proper in considering I simply want to regulate the present code for the primary line offered on this edit, to not use:

add_action('pre_option_blog_public', '__return_zero');

However as an alternative the road you graciously offered earlier:

add_filter( 'option_blog_public', '__return_false' );

Ideas?