Jetpack uses the WordPress REST API to handle the different options presented on the Jetpack dashboard page. It would be worth changing where your function is hooked, and hook it later, once the REST API has been loaded as well. I haven’t tested it, but you could try using the template_redirect hook, for example.
Let me know how it goes.
That did not work. I modified my code, which is even more hacky now which I do not like, but at least it works. Basically it’s the calls to the plugin file that are breaking it, not sure if there is a better method to write this:
/* FORCE LOGIN ACROSS ENTIRE SITE
================================================== */
add_action('parse_query',function(){
$siteURL = 'http'.(empty($_SERVER['HTTPS'])?'':'s').'://'.$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];
$siteURL = parse_url(str_replace(get_bloginfo('url'), '', $siteURL));
if(
substr($siteURL['path'],0,27)!='/wp-content/plugins/jetpack'
&&!is_user_logged_in()
&& !in_array($_SERVER['PHP_SELF'],array(
'/wp-login.php',
'/wp-register.php',
))
&& !is_page_template( 'page-templates/VT_signup.php' )
):
auth_redirect();
endif;
});
What happens if you hook your original function even later? You could try shutdown, since it’s the last action available.
Let me know how it goes.
That did not work either. All of those still force the files referenced in /wp-content/plugin/jetpack to the login page still. However, I did come up with this cleaner work-around, that with the correct url references now, should be able to copy/paste into any theme:
/* FORCE LOGIN ACROSS ENTIRE SITE
================================================== */
add_action('parse_query',function(){
$currentURL = 'http'.(empty($_SERVER['HTTPS'])?'':'s').'://'.$_SERVER['SERVER_NAME'].$_SERVER['REQUEST_URI'];
if(
( !defined(JETPACK__PLUGIN_DIR) || strpos($currentURL, plugin_dir_url(JETPACK__PLUGIN_DIR)) !== false )
&&!is_user_logged_in()
&& !in_array($_SERVER['PHP_SELF'],array(
'/wp-login.php',
'/wp-register.php',
))
):
auth_redirect();
endif;
});
Since the files in the plugin directory are the ones causing the issue, I can just check if the current URL is in that plugin’s directory.
That’s interesting. It might be worth updating to Jetpack 4.3.1, and then revert to the original version of your code, just to make sure the problem isn’t just caused by some of the issues we fixed in Jetpack 4.3.1.
If that doesn’t help, could you open the browser’s dev console, expand the JavaScript error, and make a screenshot so I can take a closer look?
Thanks!
-
This reply was modified 9 years, 4 months ago by
Jeremy Herve.
That does seem to fix it by upgrading it. I will keep an eye on it and let you know if anything changes in future patches. Thanks for your follow up on this.
