It would be interesting to know which code you used to make this change? Because depending on this, we could tell you why access is still possible when 2 “/” are specified in the URL.
I followed some howto’s easy find:
downloaded the wp-login.php file
renamed the wp-login.php to newname.php
Openup the file and with the find and replace n the Find field, enter wp-login. In the Replace field, entered my new URL path newname
then uploaded the file.
update: ad the end of the replacing you MUST cancel the wp-login.php
- This reply was modified 3 hours, 35 minutes ago by .
Resolved: after the replace of the newlogin.php file, by mistake i didn’t cancelled the original wp-login.php file and the bot find the way to bypass the code and the Nginx server directive simply adding a double slash at the url: //wp-login.php
Sorry for wasting your time
With this you change the WordPress core. Your customisation will be reset with every WordPress update and support would no longer be possible. I would strongly advise you not to do this.
Alternatively, I have another suggestion to secure your backend. Do not change the URL but restrict access by a server-side configured access request via HTTP authentication. I think some hosters like Raidboxes already offer this for WordPress installations. You can find a rough guide here:
Also have a look at this article regarding further security:
Thanks for your reply.
But I will have to see if the file wp-login.php will be added again at every update.
If is it so, I have to cancel it.
If not, I don’t have to worry because the new login file has nothing to do with the core files, because the customisation was both in the code and in the filename.
I was looking for other kind of protection, as you are kindly suggested, but they give us some problem to by implement for our organisation.
Thanks anyway for your suggestion