Maintenance Redirect

This plugin is designed to block only the normal display of pages in the web browser. It will not effect any other calls to WordPress, such as the Rest API. This means that services such as the PayPal and Stripe integrations in WooCommerce, for example, are still able to function for testing WooCommerce stores. It also means that all of the usual WordPress REST endpoints are active. If you wish to completely lock down your site's data then you will need to find an additional solution to block those calls.

There is a filter which allows you to programatically bypass the redirection block: wpjf3_matches This allows you to run pretty much any test you like, although be aware that the whole redirection thing runs before the $post global is set up, so WordPress conditionals such as is_post() and is_tax() are not available. This example looks in the $_SERVER global to see if any part of the URL contains "demo" function my_wpjf3_matches( $wpjf3_matches ) { if ( stristr( $_SERVER['REQUEST_URI'], 'demo' ) ) $wpjf3_matches[] = ""; return $wpjf3_matches; } add_filter( "wpjf3_matches", "my_wpjf3_matches" ); Props to @brianhenryie for this!

By default, Maintenance Redirect uses the manage_options capability, but that is normally only applied to administrators. As it stands, a user with a lesser permissions level, such as editor, is able to view the admin side of the site, but not the front end. You can change this using this filter: wpjf3_user_can This filter is used to pass a different WordPress capability to check if the logged-in user has permission to view the site and thus bypass the redirection, such as edit_posts. Note that this is run before $post is set up, so WordPress conditionals such as is_post() and is_tax() are not available. However, it's not really meant for programatically determining whether a user should have access, but rather just changing the default capability to be tested, so you don't really need to do anything other than the example below. function my_wpjf3_user_can( $capability ) { return "edit_posts"; } add_filter( "wpjf3_user_can", "my_wpjf3_user_can" );

Yes, there is no problem when using access keys. However, using the IP address whitelist is now a little more problematic as, due to an over-zealous security researcher, I have been forced to drop the support for testing the http X-FORWARDED-FOR header which supplies the original IP address rather than the proxy IP address. This is unfortunate as it means that you will have to whitelist the proxy's IP address rather than the end-user's address.