Use in Staging/Production Environments

Maybe something like this?

<?php  
/**
 * Bypass Force Login to allow for exceptions.
 *
 * @param bool $bypass Whether to disable Force Login. Default false.
 * @return bool
 */
function domain_based_forcelogin_bypass( $bypass ) {
    // Get visited domain
    $domain = get_site_url();

    // Bypass login on production, force login on staging
    if ( str_contains($domain, 'productiondomain.com') ) {
        $bypass = true;
    } elseif ( str_contains($domain, 'stagingdomain.com') ) {
    	$bypass = false;
    }

    return $bypass;
}
add_filter( 'v_forcelogin_bypass', 'domain_based_forcelogin_bypass' );
?>

Would that work? Can you suggest improvements?

Some thing like this would not short-circuit required login to access the WordPress admin area in any case, right?

Hi, thanks for using Force Login!

When you push/pull your changes between sites, are you able to ignore the Must-Use Plugins directory? If so, you could try adding the plugin only to the Staging site’s /wp-content/mu-plugins/ directory to avoid the database storing the active status of the installed plugin.

Another option would be to add code that disables the Force Login plugin only on the Production site using the deactivate_plugins() function. Something like this:

<?php
// Disable 'Force Login' for production site
$force_login_plugin = '/wp-force-login/wp-force-login.php';
if ( 'productiondomain.com' === $_SERVER['HTTP_HOST'] && is_plugin_active( $force_login_plugin ) ) {
    deactivate_plugins( $force_login_plugin );
}
?>

Lastly, you could use the bypass filter as you suggested. I would write the conditional statement to be more vague to allow the same code to work across multiple sites. Something like this:

/**
 * Bypass Force Login to allow for exceptions.
 *
 * @param bool $bypass Whether to disable Force Login. Default false.
 * @return bool
 */
function my_forcelogin_bypass( $bypass ) {

  // Allow non-staging site to be publicly accessible
  if ( strpos( $_SERVER['HTTP_HOST'], 'staging' ) === false ) {
    $bypass = true;
  }

  return $bypass;
}
add_filter( 'v_forcelogin_bypass', 'my_forcelogin_bypass' );

• This reply was modified 10 months, 1 week ago by Kevin Vess. Reason: simplified the deactivate plugins example code

Thanks so much Kevin! I hope that each of those options might be helpful to someone reading this thread in the future.

I’ll check with my hosting provider regarding that mu-plugins option.

Thanks for the improved code for the bypass option! Much appreciated.

For me, the “deactivate plugin programmatically” option would only help if there were also an else which activated it when copying down from the production site (where it would be deactivated) to the staging site. Deactivate when copying up to production, activate when copying down to staging. ( I also think I should check to be sure the plugin is installed, no?) Something like:

<?php
// Disable or enable 'Force Login' plugin for production or staging
$force_login_plugin = '/wp-force-login/wp-force-login.php';
// Make sure the plugin is installed
$plugin_file = WP_PLUGIN_DIR . $force_login_plugin;
$is_installed = file_exists( $plugin_file );
if ( $is_installed && 'productiondomain.com' === $_SERVER['HTTP_HOST'] && is_plugin_active( $force_login_plugin ) ) {
	deactivate_plugins( $force_login_plugin );
} 
elseif ( $is_installed && 'stagingdomain.com' === $_SERVER['HTTP_HOST'] && is_plugin_inactive( $force_login_plugin ) ) {
	activate_plugins( $force_login_plugin );
}
?>

Or for clarity, perhaps:

<?php
// Disable or enable 'Force Login' plugin for production or staging
// Conditions:
// Where are we?
$environment_domain = $_SERVER['HTTP_HOST'];
// plugin is:
$force_login_plugin = '/wp-force-login/wp-force-login.php';
// Make sure the plugin is installed
$plugin_file = WP_PLUGIN_DIR . $force_login_plugin;
$is_installed = file_exists( $plugin_file );
// Active state
$is_active = is_plugin_active( $force_login_plugin );
if ( 'productiondomain.com' === $environment_domain && $is_installed && $is_active ) {
	deactivate_plugins( $force_login_plugin );
} 
elseif ( 'stagingdomain.com' === $environment_domain && $is_installed && !$is_active  ) {
	activate_plugins( $force_login_plugin );
}
?>

What problems do those present?

That said, the bypass option seems much simpler than either of these. Are there any real advantages of using an activate/deactivate solution instead of a bypass solution?

Thanks again for your help with this!

I should check to be sure the plugin is installed, no?

Using the is_plugin_active() condition is enough to check if the plugin is installed and active. If it’s not installed, it will not return true when checking if it’s active.

Your else if statement only needs to check if it’s not active because I assume you want it activated for any site except the live site:

else if ( ! is_plugin_active( $force_login_plugin ) ) { }

With that being said, using the bypass filter instead of activating/deactivating should be fine.

A possible advantage to using the deactivate_plugins() method might be a slight performance boost if you only run that check with the admin_init hook instead of when each page loads on the front end. Also, deactivating the plug can ensure no conflicts with other plugins.

Thanks and good luck!

Thank you so much! It’s very generous of you to help me to understand this. Last question, I think… (no coding required!)

Does the admin_init hook fire on front end pages? The idea is to force any visitor to use the WordPress login to view pages in the staging site. If they visit the URL of a front end page in the staging site (where the plugin might or might not already be active) and the Force Login plugin has not yet been activated by the above code, will the admin_init hook be fired at all?

admin_init?is triggered before any other hook when a user accesses the admin area.

https://developer.www.ads-software.com/reference/hooks/admin_init/

The admin_init only runs when a user accesses the admin area.

So, as long as you’re accessing the admin area after pushing changes to your site and checking everything went up correctly, it should run your script added to that hook.

If you don’t think you’ll access the admin area after pushing your changes, you might want to use the other methods I suggested.