Symphony.

How are you handling the issue of creating a slug for entries? I have read a bunch of old forum posts and checked out a couple of extensions trying to find the right combo to be able to:

1. Name my entry
2. Have a slug field auto fill (like the @handle attribute - but editable)
3. The slug field stays the same until I change it - it does not change if the entry name changes. (I know I'm not supposed to talk about wordpress, but they do this well...)

I have seen talk about this, but it has been several years since some of these requests, so I figure someone must have some kind of solution in place... I just can't figure it myself.

If I attempt to stumble my way through the creation of a field like this will I be reworking a problem that has already been solved?

Thanks for reading.

Do you like this slug to be configurable? If you just want to create a unique URL that doesn't change if you edit an entry's title, you could make use of the system id which is attached as attribute to each entry element in the XML output.

Personally, I think it's common in the community to just use an entry's title handle.

I'm looking at transitioning an old site and would like to avoid redirecting every page on the site. Most slugs will be the @handle (maybe 60-70%?), the rest are close to the @handle, usually because the page title is too long, or would cause repetition in the url.

The system id is really not an option for me, SEO is a big deal around here and my urls need to be pretty (and not change).

It's somewhere on the forum ... dunno where. But here goes:

Given the handle of an Entry title may change over time, for future-safe slugs, I'd suggest this thing:

{entry/title/@handle}-{entry/@id}

You will end up with titles like: http://example.com/articles/lorem-ipsum-223/. Filtering will be done by Entry ID, not title handle.

It's a pretty URL, readable by humans and future proof. All these will return entry with ID 223:

http://example.com/articles/lorem-ipsum-4-223/
http://example.com/articles/anyhtihng-can-go-here-223/

For URL parsing, install URL router extension. Create a rule with these settings:

From: /\/articles\/.*-([0-9]*)/\/
To: /articles/single/$1/
Force re-route even if page exists: check it

Nota bene: in this example, there is a page Articles and a page Single with a Page param id and parent set to Articles. Use this $id Page parameter to filter the Single Article datasource.

If you don't like this idea, you can simply add a TextBox field named Permalink / Slug to your section and tell authors to fill that value only with handles :)

eg: lorem-ipsum-dolor-sit-amet

Downside of @handle filtering? When authors change the Permalink value, your visitors will end up with dead 404 pages. Using the ID for filtering, the URI will die only when Entry is deleted.

Thanks for your responses.

I am afraid I am going to end up with a basic text field for manually including a slug :(

If I do this, and later create a special field type that has a default value, is it possible to convert the vanilla text field into the new special field type? Or will I have to copy all of my slugs over manually down the road if I do this?

I am afraid I am going to end up with a basic text field for manually including a slug

I do this myself, and it's not a bad thing. I also sometimes (regarding trusting the client) add a javascript to the admin that will make the field editable on the 'new' screen, and readonly on the 'edit' screen, so they can't change it.

You know what some clients are like...

Client: Why has my entry gone from the site?

Me: Did you edit the slug?

Client: Yes, but why has it gone?

Me: *facepalm*

If I do this, and later create a special field type that has a default value, is it possible to convert the vanilla text field into the new special field type? Or will I have to copy all of my slugs over manually down the road if I do this?

Yes. But you will need some database work to do it. It would mean changing the field type in the fields table, and matching the new schema, and changing where the field's ID sits in the relevant field type table.

If you do this, when you get to it, one of us can help you do this.

It might be easier to just go with the method i mention above though for ease of pain.

Thanks @designermonkey, I really like the idea of making the field editable in 'new' and readonly in the 'edit' screen - could you point me in the right direction to do this?

When I get to work, I'll dig out the code.

Alright, I took a hatchet to this problem and got something from it. I added a little code to the field I made to switch it to readonly, but I'd still be interested to see what you have @designermonkey - I got the feeling you had a different approach than what I used.

I get the feeling there isn't much (if any...) demand for this, but I needed it so I may as well share on the off chance someone else does too.