We've set up an author entry listing template for our Movable Type blog using the recommended archive mapping of "author/%-a/%f" from this page: http://www.movabletype.org/documentation/appendices/archive-file-path-specifiers.html
We're having an issue where with some authors, a hyphen and a number gets added to the path, ie: nate-2 or valli-1.
Does anyone know why this might be happening? Though I can deal with this by generating links to this template automatically, it makes for an ugly permanent link. Any insight anyone can offer would be appreciated. Thanks in advance!
Reported on Movable Type 4.2
To be clear, the problem is with <mt:AuthorBaseName>… <mt:AuthorDisplayName> still displays the unmodified name as it should.
Finally found someone else writing about the same problem:
http://forums.movabletype.org/2008/09/altered-archive-mappings.html
I'm speculating, based on that post, that this is an issue which has been solved in releases since 4.2. (Can anyone confirm this?) Since it's not practical for my organization to upgrade right now, I found an alternate solution to my particular problem.
I got out of the <mt:AuthorBasename> business entirely and used <mt:AuthorDisplayName separator="-" lower_case="1"> in my archive mapping rather than the shortcut %-a (or %a) for the authorBasename. This lowercase, hyphen-separated display name seems to work just fine for having attractive, permanent URLs that are not vulnerable to the basename problem.
Actually, these aren't permanent at all. What you've done is re-instate the problem that basenames(of all kinds) were initially created to solve: the display name can be edited, even by the users themselves. Once that happens, the entire filename for that person's author archive is going to change rather than just have a number tacked onto it. So, really you've traded one version of the problem for another which is just somewhat less likely. This will also affect pretty redirects for profile pages, and possibly a few other things depending upon your particular usage.
Your bug was fixed in 4.25. If you can't actually do a proper upgrade to that, I would strongly suggest at least implementing the the changes linked at top there(it's small) instead of leaving this mapping lying around "to be fixed later," which it probably won't.
Anyone from 6A care to address this issue? I've discovered that if you ever change the person's display name that MT tacks the "_1" onto the AuthorBasename.
It would be great if I could easily set the MT author basename path.