Symphony.

I'm trying to use the content of an entry title field (=text field) in the URL to allow easy URL's: "www.example.org/mytitle/" instead of "www.example.org/2596/" which is the entry id. In my datasources I added a filter on the title so I only get this record, which speeds up processing.

The problem is that it does not do well with exotic titles: "www.example.org/mytitle is really great/" or "www.example.org/Starsky & Hutch/"

Obviously, URL encoding these titles makes strange URL's like "www.example.org/Starsky+%26+Hutch/".

Instead, I would prefer "www.example.org/StarskyHutch/" or even ""www.example.org/StarskyAndHutch/".

My approach would be to add an additional field that will automatically be filled upon insert / update of a target field with an tweaked version of the provided value.

However, I don't want to reinvent the wheel :) Does anyone already have experience with this kind of friendly URL's? Or should I start creating one?

Have you tried using the @handle of the field to make the URL's?

eg. Starsky & Hutch becomes starsky-and-hutch.

If you want to use something else, the Reflection Field will be able to help.

Hahaha, yes! I totally forgot about that @handle attribute, you rock! Will it also deal with other strange characters, like ',:,;. etc?

Will it also deal with other strange characters, like ',:,;. etc?

Yes, it should.

Yep, @handle removes all odd characters and just leaves numbers, letters and -.

It even has some transliterations, hence & to and.

Aside: Symphony seems to have some 'generic @handle handling' (heh) right? Most (all?) text-fields have a @handle which is automagically generated.

I wonder though: does this magic take the unicity (is that even a word?) in account? Normally @handles should be unique and, e.g. given two titles "Foo Bar" the second should be converted to foo-bar2 or something.

@david: good point, although less of a problem for me. I also filter on the member-id and there is a constraint to ensure each member has unique titles. That way, the entries are always unique.

Yeah filtering on (unique) @id is often best anyway…

I wonder though: does this magic take the unicity (is that even a word?) in account? Normally @handles should be unique and, e.g. given two titles "Foo Bar" the second should be converted to foo-bar2 or something.

A long, long time ago, Symphony exhibited this behavior. However, it was a poor assumption. It might be a handy feature for blogs, but there were several use cases which proved that it did not belong in the core.

My approach is to format the URL as /id-handle, and then have a .htaccess rule that strips off the handle and passes only the ID to the Symphony page, which then filters on that. So the handle is only there as a human-readable component of the URL and has no effect on which entry gets displayed. This way, if I decide to change the title of the entry, the URL does not break.

Occasionally I'll set up an explicit "handle" field, but most of the time I just use the above method because it's easier once it's been set up.

@tachyondecay that's quite clever (I've run into issues before with changed URL's because of changed Title's). But it does sound like a bit of a hassle to set up and it does still result in suboptimal (though better) handles (as in 12-my-first-post is less readable/friendly then my-first-post).

A middle ground would be a reflection-field handle 'linked' to e.g. a title text-field. This handle field should be populated the first time an entry (-title) is saved but not automatically change later. This would prevent broken links and would still allow us to have a handle that could be changed later. Maybe something different than the title, something that's even better for 'friendly URL's'.

This would make for a neat little field: extension no? Basically a reflection text-field that's only automatically populated on first save.

@Lewis I see. I wonder about those use-cases. I can't see when having duplicate handles would be preferred.

Also, there is the Unique Input Field. Wich either throws an error on handle-collision or simply creates a new, unique one.

@david: changing the title does really matter, does it? This is only a problem for SEO, where you want the item to be found by it's original URL. But if you use your URLs from a secure environment which the search engine cannot access (using the suburb Members extension), there is no need to care about "old" url's.

From memory the Textbox field will generate unique handles by default if you require that feature.

From memory the Textbox field will generate unique handles by default if you require that feature.

I'm not sure what field you are referring to... As for the standard core Input Field, it does not create unique handles (and shouldn't)).

@Lewis I see. I wonder about those use-cases. I can't see when having duplicate handles would be preferred.

That's partly because you're making an assumption. Unfortunately, that discussion is lost to the inter-webs as it was pre Overture Forums I believe. I specifically had a problem with it but I can't remember my scenario. Just don't make an assumption that the entry is a post or article etc.

Sorry was on my phone when I replied, Textbox Field

This is only a problem for SEO, where you want the item to be found by it's original URL. But if you use your URLs from a secure environment which the search engine cannot access (using the suburb Members extension), there is no need to care about "old" url's.

I disagree fundamentally. Cool URIs don't change. Broken links irk me on a deeply philosophical level.

I realize, of course, that such a stance is idealistic and sometimes difficult to maintain in this strange thing we call "reality". Sometimes URLs change and the old URLs can't be redirected for some reason (usually relating to Cthulu or another Old One). However, maintaining URLs is still an important component of design, even when access is limited. It's not only about SEO. :)

@Remie I am with @tachyondecay (an @Cthulu) on this one: cool URIs don't change (ideally :) ) But, pragmatically speaking you're right of course.

@Lewis re: duplicate handles - sure: I am making an assumption. I can see why that could be a problem.

@phoque the (functionality of the) unique input field is exactly needed for my 'ideal slug field': a combination between a handle-izing field, a (modified for 1-time populating) reflectionfield and the unique input field.

Let's call it the 'Cthulhu-approved™ franken-field' :)

@tachyondecay: the URL's i'm creating are directly linked to a list created by the user (for instance, a task list). If the user makes an edit on the task, the URL changes. There is no point in preserving the old URL, for the old task does not exist anymore. Proper 404 handling should redirect the user to the task list saying that the request task is no longer available and showing the proper current task list.

So I agree to your ideologie, but only to the extend that I do accept that there are certain situation in which it is not applicable (most of them in the context of user specific content).