Make it easier for a non-standard URL to be used to access wp-admin

[caesarsgrunt]

For some sites it is vital that the admin be accessible via a path other than /wp-admin/. Clients sometimes require this because it is easier for their users. Also, it is useful if replacing another CMS with WordPress for the root of the admin to have the same URL, although this can be partially fixed with a redirect.

Even when not required per se, some of us prefer to use a different URL to access the admin because it is more intuitive for our users to use something like /admin/ instead of /wp-admin/.

To be clear: I am not suggesting renaming the wp-admin directory, nor am I suggesting adding an option in the UI to change the path.

Rather, I am suggesting that small tweaks be ade to make it easier for power-users to enable the use of a different URL to access the admin area.

I suggest making the following changes :

1. Use relative urls within the admin where possible without affecting standard installations.

2. Allow power-users to add a constant to wp-config.php to change the path of the admin for those links which have to be absolute.

I don't think there is much work involved and I am happy to do it.

Core devs have in the past stated that the user of alternative urls to access the admin is 'not supported', but it is unclear whether this simply means that it doesn't work at the present time or that the core team is opposed to allowing it to happen.
If the latter is the case, I would appreciate an explanation - I'm sure there is a good reason if that is the case, but I can't for the life of me think what it could be. ;)

[caesarsgrunt]

I would like to emphasise that I am not suggesting that people should move any files.
Specifically, the point of this ticket is to make it possible to change the url used to access the admin from example.com/wp-admin/ to example.com/admin/ without having to move any files.

I will dig through the code I've used for some of my clients and post the code I'm using at the moment.

[caesarsgrunt]

Ok... here is the code I've used for this in the past. Two parts, one in a plugin and one in .htaccess. This code also changes example.com/wp-login to example.com/login.
A few function and variable names have been changed to protect the identity of my client, but the functionality is the same.

In a plugin :

/**
 * HACK : Change admin urls to /admin/ instead of /wp-admin/.
 * Only works in conjunction with some complex rules in .htacces.
 */
function caesarsgrunt_admin_url($url, $path) {
	return str_ireplace('/wp-admin/', '/admin/', $url);
}
add_filter('admin_url', 'caesarsgrunt_admin_url', 10, 2);
add_filter('network_admin_url', 'caesarsgrunt_admin_url', 10, 2);

/**
 * HACK : Change login/out urls to /login/ instead of /wp-login.php.
 * Only works in conjunction with some rules in .htacces.
 */
function caesarsgrunt_login_url($url) {
    return str_ireplace('/wp-login.php', '/login/', $url);
}
add_filter('login_url', 'caesarsgrunt_login_url', 10, 1);
add_filter('logout_url', 'caesarsgrunt_login_url', 10, 1);
add_filter('site_url', 'caesarsgrunt_login_url', 10, 1); // because wp-login.php uses this when linking to itself
add_filter('network_site_url', 'caesarsgrunt_login_url', 10, 1); // because wp-login.php uses this when emailing the user

/**
 * HACK : Prevent redirect from /login/ to /login/wp-login.php.
 * Part of the /login/ hack. After logging the user out, wp-login.php redirects to itself using a hard-coded url.
 * This results in a redirect from /login/ to /login/wp-login.php.
 * Here we prevent that by catching the redirect and changing it to /login/.
 */
function caesarsgrunt_wp_redirect($url, $status) {
    return str_ireplace('wp-login.php', '/login/', $url);
}
add_filter('wp_redirect', 'caesarsgrunt_wp_redirect', 10, 2);

In .htaccess : (may be buggy, I'm not an htaccess expert, but it works fine)

# 301 redirect /wp-admin/ to /admin/
# infinite loop avoided with the second cond
# NE prevents re-encoding query vars, which are likely to already be encoded
RewriteCond %{HTTP_ACCEPT} text/html
#RewriteCond %{THE_REQUEST} ^GET\ (.*)/wp-admin/
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule ^([_0-9a-zA-Z-]+/)?wp-admin/(.*)$ $1admin/$2 [R,L,NE]

# internally redirect /admin/ to /wp-admin/ - if the file exists in the latter
RewriteCond %{DOCUMENT_ROOT}/wp-admin/$1 -f [OR]
RewriteCond %{DOCUMENT_ROOT}/wp-admin/$1 -d
RewriteRule admin/(.*)$ wp-admin/$1


# internally redirect /login/ to /wp-login.php
RewriteRule login/$ wp-login.php


# add a trailing slash to /admin and /login
RewriteRule ^([_0-9a-zA-Z-]+/)?admin$ $1admin/ [R=301,L]
RewriteRule ^([_0-9a-zA-Z-]+/)?login$ $1login/ [R=301,L]

# remove multiple slashes anywhere in the url
RewriteCond %{REQUEST_URI} ^(.*)//(.*)$
RewriteRule . %1/%2 [R=301,L]

[caesarsgrunt]

Now... here's what I'd like to be able to do instead.

In wp-config.php

define('WP_ADMIN_URL', 'admin');
define('WP_LOGIN_URL', 'login');

The rest could be achieved internally with only slight modifications to core.

In this case I prefer using a constant in wp-config rather than a filter, because this is something you will want to define once and leave, and it seems a pity to load extra code in the form of a plugin for a one-off change like this, when it could be done so simply with a constant.

[caesarsgrunt]

Replying to caesarsgrunt:

Ok... here is the code I've used for this in the past. Two parts, one in a plugin and one in .htaccess. This code also changes example.com/wp-login to example.com/login.

I missed a bit...

In wp-config.php :

define('ADMIN_COOKIE_PATH', '/');
define('PLUGINS_COOKIE_PATH', '/');

[caesarsgrunt]

With the patch, the path used to access wp-admin can be changed as follows :

in wp-config.php

define('WP_ADMIN_URL', 'admin');
define('ADMIN_COOKIE_PATH', '/');

in .htaccess

RewriteCond %{DOCUMENT_ROOT}/wp-admin/$1 -f [OR]
RewriteCond %{DOCUMENT_ROOT}/wp-admin/$1 -d
RewriteRule admin/(.*)$ wp-admin/$1

It would be possible to simplify this further, but this is just a first run. Feedback would be greatly appreciated.

[westi]

I'm not convinced by the naming or use of the WP_ADMIN_URL define.

I don't think we should need code to support this.

We should ensure that this can be done with a htaccess file stanza and some plugin filtering of generated urls.

[caesarsgrunt]

Replying to westi:

I'm not convinced by the naming or use of the WP_ADMIN_URL define.

The name could be changed to anything else...

I don't think we should need code to support this.

It's only one constant, accessed in three places. (And also a redirect, in my patch, though that isn't vital.)
Does that cause any problems? It seems (to me) so trivial, and it reduces the code needed to do this by such a huge amount in both extent and complexity.
So far as I can see it causes no problems for standard installations - does it?

I'm puzzled as to why there is any objection to such a small amount of code... :-)

We should ensure that this can be done with a htaccess file stanza and some plugin filtering of generated urls.

Well, it can - but as you see from my code above, it's quite complex when it could be quite simple.

[caesarsgrunt]

The redirect in particular is nice actually, since it obviates the most complex and ugly part of the htaccess code...

[zgtc]

where do we vote +1000 on this?

[SergeyBiryukov]

Related: #7194, #13118, #24673.

[c3mdigital]

We have redirects for /admin /login and dashboard /dashboard. I agree with westi that as long as it is possible for plugins to change this with url filters and or .htaccess that it shouldn't be changed in core.

[nacin]

Strongly agree on closing this.

[caesarsgrunt]

I honestly don't understand the objection to this; all it involves is changing three instances of the hardcoded string wp-admin to use a constant instead.
What are the disadvantages to making this change? Please enlighten me.

[nacin]

Replying to caesarsgrunt:

I honestly don't understand the objection to this; all it involves is changing three instances of the hardcoded string wp-admin to use a constant instead.
What are the disadvantages to making this change? Please enlighten me.

1. Adding this to core increases the cost of maintenance. We then have to account for this in everything we do in the future. It becomes a new setup for which we need to test. And we can't break it if there is a future need to do so.

2. The things that are "hardcoded" are in fact filterable.