I may be missing something but the WordPress Codex for “the_author_posts_link()” function says this:
Displays a link to all posts by an author. The link text is the user’s Display name publicly as field. The results of clicking on the presented link will be controlled by the Template Hierarchy of Author Templates.
So as long as a theme is utilizing the_author_posts_link(), the display name should always show up anyway. The username should never be shown.
In fact, this plugin seems to break linking to the Display Name at least in WP 3.5.
I don’t see any reason for this plugin in the current version of WP.
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.
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 (http://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.
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. 😉
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_nicenamefield in the
wp_userstable in the database are NOT the same thing. The username is saved in the database in the field
user_login. The field
user_nicenameis what’s used to display the author slug. The Nickname field from the backend is NOT saved in
wp_userstable, but in
wp_usermetatable. It is saved as a meta_key named
nicknamewith the value you’ve specified from the backend.
This, again, triggers the question of why the
user_nicenamefield 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.
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.
- The topic ‘Plugin not useful’ is closed to new replies.