is_login() fails on non-standard WordPress installations.

[Levdbas]

is_login() uses

$_SERVER['SCRIPT_NAME']

as the needle in stripos() where this function relies upon. In non-standard WordPress installations, for example Bedrock, where the root is different the following would be checked:

haystack: ​https://domainname.org/wp/wp-login.php
Needle: web/wp/wp-login.php

And thus fail.

Would it be possible to update this function so these non-standard installs will work as well? By example, maybe only check for wp-login.php instead of the full path?

[iandunn]

For background, the function was introduced in r53884 (and renamed in r54447), see #19898. There's ​a variety of techniques in WPSE that might help cover edge cases.

@Levdbas, can you provide a copy of your full $_SERVER and ABSPATH? Feel free to redact any sensitive bits, I'm just interested in seeing what values could be used to cover your use case.

[Levdbas]

Hi @iandunn

I did some more digging and it is more specific then I thought. I only experience this issue when using a custom .htaccess snippet on Directadmin (Apache) servers.

RewriteEngine on
RewriteCond %{HTTP_HOST} ^example.com$ [NC,OR]
RewriteCond %{HTTP_HOST} ^www.example.com$
RewriteCond %{REQUEST_URI} !web/
RewriteRule (.*) /web/$1 [L]

This results in /web/ being added to

$_SERVER['SCRIPT_NAME']

and thus breaking the logic.

Domains with proper webroot settings or sites running on Nginx servers is_login() working as intended, even with Bedrock/custom root.

Needle on my directadmin/.htaccess solution: web/wp/wp-login.php, which fails
Needle on other servers: wp/wp-login.php, which succeeds

So I think my reported issue is a bit too specific for core. Next time I will do some more research before opening a ticket.

If you think otherwise, I will provide the $_SERVER and ABSPATH as requested.

[SergeyBiryukov]

Thanks for the follow-up!