Default Slug Format

[MoritzLost]

It would be great to have an option to define the default slug format for entries, similar to the default title format.

A common scenario is that you want URLs to have a specific structure, but still allow users to change the URL for some entries. But this is difficult because the slug is always generated based on the title.

For example, I have a channel for Podcast episodes. The podcast entry type has an episode number field and a title. For most entries, I want a URL structure like this: podcasts/{episode}-{title}, e.g. podcasts/123-foobar. But for some specific podcast episodes, the authors want to be able to use podcasts/my-special-seo-optimized-url.

I have two options here:

1. Hardcode the {episode} in the URL, which will not allow authors to create URLs without the episode number.
2. Use podcasts/{slug} as URL format for maximum flexibility. However, the title is just the topic without the episode number, so then you have to remember to always manually add the episode number to the slug, or you will end up with URLs like podcasts/foobar without the episode number by default.

There are various ways to move the problem around, but the issue remains that you're entering the episode number at least twice.

I think the best way to solve this would be to add a Default Slug Format setting to entry types, similar to the Default Title Format. That would allow me to specify the default slug format based on other fields than the title, but still allow maximum flexibility for authors to use different slugs.

[brandonkelly]

Another option you could do is create a “Custom URI” field, which overrides the default {episode}-{title} format when filled in:

podcasts/{{ customUri ?? "#{episode}-#{slug}" }}

Or, a “Include episode number in URI” Lightswitch field, which is enabled by default:

podcasts/{{ includeEpInUri ? "#{episode}-" }}{{ slug }}

[MoritzLost]

@brandonkelly Absolutely, those are solid workarounds. However, they're not without drawbacks. Having a custom URI field is awkward for the author experience, because then you have two separate inputs (the custom field and the native slug) that do the same thing. It's not clear to authors why there are two, and which one they should use. I can hide the slug, of course. But this will be confusing for authors – why is the field to edit the URL now a custom field in the main entry form, instead of the slug in the sidebar like all other entries?

Those are definitely workable solutions, though I would still like to see an option to modify the auto-generated slugs. For now, I'll see if I can modify that using hooks.