URL Rewriting: Name instead of ID

[eluser]KingSkippus[/eluser]
[quote author="mddd" date="1279731640"]Then the topicstarter should just stick to using id's. I don't see the value in using names instead of id's, but encoding the names in a way that is hard to read by the user.[/quote]

I agree, the OP probably really should stick to using ids. Otherwise, he or she is asking for a royal PITA when users go guessing what to enter as the URL. Should they enter:

- .../john_doe?
- .../john doe?
- .../john-doe?
- .../john%20doe?
- .../johndoe?
- .../John_Doe?
- .../JohnDoe?
- ...

Not to mention, what happens if you have two John Does in your database? Are you going to resort to .../john_doe and .../john_doe2? That's not user-friendly at all.

Don't get me wrong, I'm not strictly opposed to using a URL like .../john_doe, because it does give the user an inkling of what to expect if they click on it--information about somebody named John Doe. Typically, though, I only do this if the database key field I'm looking up is actually john_doe and not some numeric id. Again, having readable URLs is gravy, but in the end, the programmer should worry more about how to uniquely use them to identify the information they need to get and present the information to the user, not letting users guess what URLs will be.

[eluser]mddd[/eluser]
What I often do to provide more readable urls, is to make urls like

Code:

www.example.com/authors/123/john_doe

Here, john_doe is just the name from the database, passed through url_title().
There may be more names that end up as john_doe after url_title() but that is no problem because the name is purely for readability. The number is what the system uses to find the record.

[eluser]perfectsam[/eluser]
Thank you guys for the various inputs.

First of all, the functions rawurlencode() and CI's url_title() are not ideal for me, since names in the db have a lot of special characters in it (äöüéàèåñ) and those functions would simply replace them with ''. müller -> mller.
I've already found a suitable function which seems to work with all names I quickly tested: http://www.php.net/manual/en/function.pr....php#96586

So basically, I want to achieve 2 things with the new URLs:
- SEO
- user-friendly URLS, so users can type in the name instead of the ID which they almost never know, hence also the removal of '/show' (<-- haven't tried that one yet)

That means your last solution (www.example.com/authors/123/john_doe), mddd, is not very suitable for me since the users don't know the ID.

[quote author="mddd" date="1279714564"]1. Why use a redirect? Why not have the page stay on its own url? It would be perfectly ok to do so. That way, name and id would be equal. Not having the name simply a redirect to the id. Think of bookmarking for instance. Wouldn't it be much nicer for the user to bookmark 'authors/john_doe' than 'authors/show/123' ? FAR more useful to keep the name in there! And better for SEO too, I would think.[/quote]
I don't quite understand this. How would I implement this? As for bookmarking, the user bookmarks 'authors/show/john_doe' with the method I use now, except when he browses the author list and right-clicks on an author and bookmarks it. The link would then be 'authors/show/123' but the bookmark title would still be the author name, so it doesn't really make a difference.

[quote author="KingSkippus" date="1279732107"]Not to mention, what happens if you have two John Does in your database? Are you going to resort to .../john_doe and .../john_doe2? That’s not user-friendly at all.[/quote]
Yes, that's a big problem. At the moment, all the names are different, but of course that can change and I agree, a john-doe2 would not be very ideal but I don't see how I could do it differently with the method I use now.
Edit: I think a slightly better way would be: The page has an add author form. I could change the add function so that it is not possible to add an author with a name (first+lastname) that already exists and tell the admin who adds the authors that when this should happen, he should add it just like this:
First Name: "John"
Last Name: "Doe (2)"
or something like that. This way, they would also be distinguishable in the author list. and the URL would look like john_doe_2


So my code looks like this now, including the url function:

Code:

if (is_numeric($author_id))
    {
        $author = $this->author_db->getByID($author_id);

        redirect('authors/show/'.make_url($author->getName()));
    }
    else
    {
        $author = $this->author_db->getByName($author_id);
    }

Now, I have to change the getByName function since it only returns the author if it's like this: "John Doe" but $author_id contains "john_doe" now and the function doesn't return anything.

[eluser]mddd[/eluser]
Please excuse me. I thought you were redirecting from name to id, but it is the other way around. If a link contains the id, it redirects to the link with the name in it. So bookmarking is not an issue.

[eluser]KingSkippus[/eluser]
I still think you're barking up the wrong tree in getting users to type names in the URL. I really think the way to go for almost every situation is to provide a textbox or some other navigational tool on your page that will do a name-to-id mapping for picking the right URL.

But I'm not the one coding your application, so if you can make it work and you're determined to have URLs used to navigate, then at the very least, I suggest making the string you're using as the URL key your database key instead of a numeric ID. It sounds like it will be used as a key anyway, and having two unique keys is a bit of a waste.

[eluser]perfectsam[/eluser]
Oh well, I finally came to my senses and didn't implement it like I initially wanted. I took mddd's solution instead (thanks!) and my links look like this now:

Code:

base_url/author/123/john_doe

I just had to change all author links to

Code:

'author/'.$author->author_id.'/'.make_url($author->getName())

and used this route in routes.php:

Code:

$route['author/(:num)/[a-zA-Z0-9\-\_]+'] = "authors/show/$1";

which works perfectly. Thanks everyone again.