Create a is_login() function similar to is_admin()

[dcowgill]

It would be useful for developers to have better detection of being on the wp-login.php and wp-register.php pages. Sure, this can currently be done by using the $pagenow global variable but having a similar function like is_admin() would make things easier/cleaner.

One use case:

-Using a hosted javascript file but then requiring SSL (FORCE_SSL_LOGIN).

function javascript_init() {
    if ( $pagenow == 'wp-login.php' || is_admin() )
        return;

    wp_deregister_script( 'jquery' );
    wp_register_script( 'jquery', 'http://ajax.googleapis.com/ajax/libs/jquery/1.6/jquery.min.js');
    wp_enqueue_script( 'jquery' );
}
add_action( 'wp_print_scripts', 'javascript_init' );

Proposed solution:
Create a new function that does all the checking.

function is_login() {
    return in_array( $GLOBALS['pagenow'], array( 'wp-login.php', 'wp-register.php' ) );
}

[scribu]

The login pages are a grey area; you're not in wp-admin, but you're not on the front-end either.

[wonderboymusic]

The attached patch does exactly what WP_ADMIN does for WP_LOGIN - adds is_login() which will be true for any page rendered by wp-login.php or any action handled by it

[nacin]

I feel like the name is_login() could cause confusion in that it could be referring to the current user (i.e. what is_user_logged_in() is for). This is already rather confusing with is_admin(), given is_super_admin() and a number of other functions (is_blog_admin, is_user_admin, is_site_admin).

wp-register.php no longer exists (and for older installs, it simply redirects to wp-login.php). That means that is_login() simply returns $GLOBALS['pagenow'] == 'wp-login.php, which is not really much of a shortcut. Doesn't seem all that needed, in that case.

[scribu]

Replying to nacin:

That means that is_login() simply returns $GLOBALS['pagenow'] == 'wp-login.php, which is not really much of a shortcut. Doesn't seem all that needed, in that case.

It would be more useful if it had a filter, which could be used for defining custom login areas for themes.

[scribu]

Actually, we don't even need a new filter. is_login() can just compare wp_login_url() agains the current URL (which I really think deserves a get_current_url() helper, btw).

Behold: 19898.2.diff​

[scribu]

19898.3.diff​:

• renames is_login() to is_login_page() and introduces is_register_page()
• adds necessary get_current_url() and wp_register_url() - see #17950

[nacin]

While get_current_url() might be a nice-to-have, it isn't needed here — remove_query_arg( array( 'action', 'redirect_to', 'loggedout' ) will automatically act against the current URL.

[scribu]

To be exact, remove_query_arg() returns the current URL, sans the domain.

Either way, remove_query_arg() isn't reliable for is_register_page(): ?action=register.

It turns out, we can just use did_action( 'login_form_login' ) and did_action( 'login_form_register' ).

The only hitch is wp-signup.php.

[scribu]

There: 19898.5.diff​

At this point, we're back to comment 6.

[robmiller]

#22852 was marked as a duplicate.

[nacin]

Replying to scribu:

Actually, we don't even need a new filter. is_login() can just compare wp_login_url() agains the current URL (which I really think deserves a get_current_url() helper, btw).

is_admin() is frequently used to decide whether we are in the admin or not for purposes of, say, loading code. Allowing is_login() to be true for a theme page doesn't really make sense, nor does it solve that wp-login.php is in no man's land. It would be better to offer a login.php template (along with signup.php, activate.php, register.php, and probably other login actions) if this was about themes.

The original use case can be solved by either checking is_ssl() or just using a protocol-relative URL (//), FWIW.

[wonderboymusic]

I currently add Apache rewrites to allow different theme'd login pages - so +1 on the theme vibe

[scribu]

A login.php template would be great, but wouldn't you need a conditional flag for template-redirect.php then anyway?

And also, for example, themes might want to do something like this in header.php:

if ( is_login() ) {
  // enqueue some custom js 
}

[kitchin]

The proposed patch Attachment 19898.5.diff​ does not work when an add_action('init', ...) callback needs to detect wp-login. In that case @$GLOBALS['pagenow'] == 'wp-login.php' does work.

My particular situation is that a plugin author used add_action('init', ...) to call session_start(). The session creation is failing due to file errors on the server, and I am disabling sessions on the admin side to debug.

Replying to scribu:

It turns out, we can just use did_action( 'login_form_login' ) and did_action( 'login_form_register' ).

[chriscct7]

So no activity has happened on this ticket for 2+ years now. The latest patch doesn't really save anyone who really wanted to use a function like this that much code, and as pointed out there's issues in the current patch. Closing as wontfix

[SergeyBiryukov]

#37483 was marked as a duplicate.

[tazotodua]

My topic (#37620) was closed marked as "DUPLICATE" of this topic.

However, MY REQUEST IS COMPLETELY DIFFERENT!

WHAT ON EARTH, if you add
define('LOGIN_PAGE_EXECUTED', true);
or something like that in wp-login.php

why dont you make a great help to programmers?

we cant determine when login page is executed (when we output login page on other page then wp-login.php url, like many security plugins do that)

[SergeyBiryukov]

Replying to tazotodua:

My topic (#37620) was closed marked as "DUPLICATE" of this topic.

That ticket is still open. That said, it's unlikely a new constant will be introduced here. Constants are not a great way to check for context, as they are not filterable and hard to use in unit tests, see the discussion in #25669.

#37483 was closed, because the IS_LOGIN_PAGE constant proposed there does seem similar to the is_login() function proposed here. Why is it "completely different"?

[iandunn]

I think this is worth reconsidering.

is_login() simply returns $GLOBALSpagenow? == 'wp-login.php, which is not really much of a shortcut

latest patch doesn't really save anyone who really wanted to use a function like this that much code

It doesn't save a lot of lines of code, but what it does save is a lot of time spent investigating the most reliable way to solve this problem.

As the various patches and ​WPSE answers demonstrate, there are a handful of ways that devs have tried to solve this problem, and many of them are buggy. I personally just spent an hour of research and testing before settling on a solution I'm happy with, and it's still possible that I missed some edge cases.

It'd save devs a lot of time and bugs if Core provided a reliable solution.

we can just use did_action( 'login_form_login' )

I think the flaw with 19898.5.diff​ is that login_form_{$action} executes after plugins have loaded, so it wouldn't solve the use case of a bootstraper that's trying to load code exclusively on the login screen.

I would do this instead:

function is_login_screen() {
	return false !== stripos( wp_login_url(), $_SERVER['SCRIPT_NAME'] );
}

[SergeyBiryukov]

Replying to iandunn:

I would do this instead:

function is_login_screen() {
	return false !== stripos( wp_login_url(), $_SERVER['SCRIPT_NAME'] );
}

Makes sense to me.

[donmhico]

Replying to iandunn:

I would do this instead:

function is_login_screen() {
	return false !== stripos( wp_login_url(), $_SERVER['SCRIPT_NAME'] );
}

Looks good to me too. I created a patch, 19898.6.diff , using @iandunn's solution. I inserted the function in wp-includes/load.php as other similar functions such as is_admin() resides there,

[davidbaumwald]

With version 5.3 Beta 1 releasing shortly, the deadline for enhancements is now passed. This is being moved to Future Release. @SergeyBiryukov if you feel this can be included in 5.4, feel free to move up the milestone.