Plugin not useful

@pha3z
I’m not quite sure what you’re trying to point here, but I think you’re talking about a completely different thing.

What this plugin says it does (and it does it quite well in WP v3.5.1) is that it changes the author’s URL/permalink slug. The function you mentioned from the Codex does a different thing: it outputs the link text from the “Display name publicly as” field, but it does not change the author’s URL.

For example:
If we had a user with the username (testname) and this user has edited the “Display name publicly as” to (Mr. Test Name). When I use “the_author_posts_link()” function in my theme, it will display a text link like this (Mr. Test Name), when you mouse over the previous link you’ll get the URL (https://www.example.com/author/testname) which used the author’s username in the permalink not the author’s display name. That way, you’re exposing usernames publicly in author URLs.

This plugin’s job is to change that link to this (Mr. Test Name) which uses, you guessed it, the sanitized version of the author’s display name as the URL.

Just a quick correction,
The author’s URL is in fact the author’s nicename not username, but still, since the nicename field in the database is automatically created from the username field and there is no obvious way to edit it without changing the value directly in the database, the majority of users will still have their nicename looking the same thing as their username.

@hassan, your explanation to @pha3z is great — but I’m afraid your correction needs a correction. ??

There are 5 fields under the heading ‘Name’ in the user’s profile settings page (wp-admin/profile.php) :

• Username (cannot be changed)
• First Name
• Last Name
• Nickname (required)
• Display name publicly as (dropdown menu of all of the above)

Usernames are chosen at registration and cannot be changed except directly in the database. They’re used for logging in, so should never be revealed publicly, for security reasons.

The Nickname, being required, is by default set to the Username, since registration only provides two fields: username and email. The registered user CAN indeed change the Nickname by logging in and going to the Users > Your Profile page (wp-admin/profile.php). — Or the admin can do it for them by going to the Users page (wp-admin/users.php) and clicking the Edit link under the user’s name in the list of users.

That’s also where you can set the Display name. It, too, is filled in by default with the Username, but should be changed.

It would be best if WordPress core code created the author URL with the Display name if available, or the Nickname as a second choice, and only fell back on the Username if nothing else was set. But unfortunately, that’s not what’s happening as of the current version (3.5.1). It uses the Username for the URL, even though you’d think having the Nickname be a required field would mean that that’s what it would use. Well, it doesn’t. That’s why this plugin is useful.

What the plugin uses is the Display name. Which is perfect, because the Display name can be set to any of the other names, including the real name if you wish, or the Nickname if you prefer, which is useful if you don’t want to use the Username for security reasons AND you don’t want to use your real name for privacy reasons.

I’m not sure whether the “nicename” is supposed to be the Nickname or the Display name, but either way, the author URL isn’t using either without this plugin (or something similar).

??

@heartwood, that was one well-structured post — but I’m afraid your correction to my correction needs another correction. ??

You wrote:

Usernames are chosen at registration and cannot be changed except directly in the database.

Totally agree with you on this.

The registered user CAN indeed change the Nickname by logging in and going to the Users > Your Profile page (wp-admin/profile.php).

This is also true. But I’ve never emphasized that you cannot do that. The issue here is, the Nickname field in the backend and the user_nicename field in the wp_users table in the database are NOT the same thing. The username is saved in the database in the field user_login. The field user_nicename is what’s used to display the author slug. The Nickname field from the backend is NOT saved in wp_users table, but in wp_usermeta table. It is saved as a meta_key named nickname with the value you’ve specified from the backend.

This, again, triggers the question of why the user_nicename field isn’t editable from the backend. And therefore what’s the purpose of the Nickname field in the profile settings. If it’s only to allow users to select other option than their real name to be displayed publicly, then it shouldn’t be required. If it was not required, nobody would’ve cared much, but being it required is what’s causing the head-scratching here as to what’s that critical thing the Nickname will be used for. Still waiting for a satisfactory answer from a core developer.

Also, another plugin that deals with the same issue is Edit Author Slug.

Finally,

It would be best if WordPress core code created the author URL with the Display name if available, or the Nickname as a second choice, and only fell back on the Username if nothing else was set.

I second this!

??

Thanks for the clarification, @hassan . I should have explored the database structure more before replying.

So if the nicename is simply the slug, i.e. a URL-friendly version of the name (currently the username), and it’s not editable without a plugin, then could it be that the original idea was to make the required Nickname be the place where you set the slug/nicename, but somehow the developers lost track of that somewhere along the way?

If the core team did get (back?) on track with a proper purpose for the Nickname (beyond giving the Display Name drop-down menu another option), it would solve the security issue without needing a plugin fix.

It would also make more sense to include the Nickname field in the registration process if it’s going to be required, because users don’t always go to their profile page to edit it after the fact.

I certainly hope the core team has got something in the works.
??