So you are saying, when the rename login page feature is turned off. The is_admin() function behaves correctly?
Yes, actually it behaves correctly on all pages even with Rename login page turned on, except the one 404 page generated by visiting /wp-admin. All other 404 pages are fine.
Yes we recently changed the code in the rename login feature very slightly so that whenever someone tries to go to the “wp-admin” slug directly when that feature is enabled they will get a 404 redirect.
(Previously they would get a message saying “Please log in to access the WordPress admin area”)
We’ll have to look more closely to see why your conditional checks are returning unexpected results.
Thanks. I have looked into your code a little bit more and the dealbreaker is really is_admin() conditional. This is set to be true, as /wp-admin initialy acts as admin request. Since processing of rename login page is on wp_loaded filter, that is far after all the theme and plugin files are loaded. The problem is, that themes and plugins are sometimes using is_admin() to load just appropriate files depending on type of request (I believe, that good themes and plugs shloud do that 🙂 ).
When the execution hits your 404 loading, you call $wp_query->set_404() and the conditionals get right at this point, but this is too late for themes/plugs to load files depending on is_admin().
Cleanest way of solution I see here is to wp_redirect to brand new 404 page and die(). In this case all conditionals would be OK from begining of the request and bots, who don’t follow Location: will get blank page, which is still fine (maybe even bettter for sake of server processing time 🙂 ).
Just little example from my life, why is can be quite deal: I load all my add_shortcode() only on frontend request (because there is no reason to load them on admin actually). In my footer, I have my e-mail address wraped in shortcode, which will obfuscate it against bots. What this bug do at the end is that on /wp-admin URL my e-mail gets printed out in plantext, since there are no shortcodes registered for that request. Not to mention styles and scripts, which won’t load either, since I don’t run all my frontend functions (including registering frontend styles) for admin requests.
This is just for better understanding of consequences, I don’t want you to deal with those specific problems 🙂
So thanks a lot once more, for considering this and thank you for great plugin.
Jakub Klapka
I just realized, that redirecting to some unique page slug could be also kind of feature. If you would wp_redirect to something like /aiowps-hidden-admin users will normally get 404 (working one). But they can create page with this exact slug and they can maybe put some notification for human-users, where they can really find admin or something like that…
Hi Jakub,
Thanks for that.
I think what you are saying is reasonable and we will look at making this a little more flexible for the user when the scenarios you suggest occur.
(Momentarily we are busy trying to fix a more urgent security bug for the rename login page feature which we want to release in our next version. This item will get attention in subsequent releases.)
