I'm disabling user enumeration for security purposes in order to prevent usernames from being revealed by looking up the user IDs. Instead, whenever someone tried to find out the username by their ID, such as visiting the following:


It will redirect them to the homepage. After searching around, I've found two plugins which have this function, but both of them use slightly different logics to check if someone is trying to enumerate:

Logic #1

if ( preg_match( '/(wp-comments-post)/', $_SERVER['REQUEST_URI'] ) === 0 && ! empty( $_REQUEST['author'] ) ) {
    # Redirect to homepage...

Logic #2

if ( ! preg_match( '/(wp-comments-post)/', $_SERVER['REQUEST_URI'] ) && ! empty( $_REQUEST['author'] ) && ( int ) $_REQUEST['author'] ) {
    # Redirect to homepage...

Both logics work, but I'm wondering which one is more effective and what they are doing differently.

Also, before I discovered this logic, I've already implemented the following functions to redirect author links to the homepage, which gives em the same result:

# Redirect author page to homepage
add_action( 'template_redirect', 'author_page' );

function author_page() {
    # If the author archive page is being accessed, redirect to homepage
    if ( is_author() ) {
        wp_safe_redirect( get_home_url(), 301 );

Is this function enough to prevent user enumeration? Or should I still apply one fo the following logics above?


Logic #1 is checking the returned value of the preg_match function with respect to 0 and with operator ===. That means the returned value of the preg_match function has to be (int) 0 or (string) 0. And after that it is checking if $_REQUEST['author'] is empty or not.

And in Logic #2 is checking the same thing above, but with !()(not) operator. And this method also additionally check the $_REQUEST['author'] is integer or not.

Checking the $_REQUEST['author'] data type actually makes Logic #2 better than above Logic #1, I think. Cause, though data type doesn't matter in PHP (PHP is a loosely typed language) but it's better to use them. It defines a concrete base for your application and ensures some core security as well as it's the best practice.

Hope that answer satisfies your quest.

  • Thanks for the code explanation, definitely helps me understand it better. – Ethan O'Sullivan Oct 18 '16 at 14:49

off-topic but probably worth mentioning - there is a different solution to the issue and this is to change the user slug to be different than the login name, for example. this can be some random variation that can be overriden for actual authors that actually have something on their pages.

In any case I am not a great believer in redirecting to random locations (why home page?). If you want to "disable" the URl serve a 404 page.

... and $_REQUEST is way too broad, and may trigger redirect on ajax request and cookies. You should care only about the URL parameter so better to probably stick with $_GET

  • Hm, now that you mention it, I already implemented a function to redirect the author URL to the homepage. See my updated question. – Ethan O'Sullivan Oct 17 '16 at 19:18
  • not sure, it needs to be tested. the redirection you are asking about is probably the result of the canonical url redirect which I think happens before the ``template_redirect` kicks in. BTW yet another way to solve this is by manipulation the canonical url for the author pages. you might want to look into filters in codex.wordpress.org/Function_Reference/redirect_canonical function – Mark Kaplun Oct 18 '16 at 2:41

If for some reason you want your security to be processed through an official plugin with the ability to disable author pages, as well a 301,307, and destination page redirect options, then try out...

Disable Author Pages

I'm currently testing it out on WP version 4.6.1 and it works.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.