Sanity slug/pathname field

[Jamiewarb]

Background

Documents that have an attached URL need a field to put this.

Potential Strategies

There's two schools of thought for Sanity slugs:

• Store the full URL
• Store just the page's part of the URL

Storing the full URL allows for simple path resolution—send the whole URL to Sanity and find the matching document

Storing just the page's part keeps it flexible and allows for flexibility changing of page prefixes, and prevents accidental editing of paths that should be the same, e.g. /articles/{slug}.

Chosen Strategy

For the initial implementation, I'd like to go with storing the full page URL.

But to negate the drawbacks, I want to use a custom slug component that supports folders, folder locking, and initial values for folder. This allows us to mitigate some of the drawbacks of storing the full path.

Needs

The pathname field should have a few features:

• Store the full URL of the page
• Turn slashes '/' into folder parts, which become read-only to prevent accidental editing
• Edit button on the folder parts to edit them when needed
• Enable locking folder parts, so they cannot be edited and the edit button is locked
• Full frontend URL should display, to see what the URL looks like
• A clickable preview button to open this URL
• A clickable generate button to generate the slug from the title (or specified field)

[liamb13]

I actually really like this approach. Would also make displaying and searching/using the URL throughout Sanity a lot easier.

Would this need a schema and publish action (to update all URLs) for the folder parts? This really should be avoided once a site goes live. But I can see a case where a last minute change to the slug structure could be requested.

One quick note; when documenting this functionality - it could be good to refer to this as the full path of a url. As I'm assuming in this context full url ≠ domain + path? Maybe even just a quick graphic like the Semrush example.

[Jamiewarb]

Yes you're right, I didn't mean to include the domain.

Sounds good. We can call the field pathname, and if the user has any documents that aren't the full pathname, they can be referred to as slug. This is how I have the fields set up already.

I contributed some of this functionality to Tinloof's studio package, so we have this functionality out of the box with them.

The implementation is fairly simplistic, in that it just uses a custom component around the string field for the pathname. The custom component handles all the "logic" and it's then just stored as a string (well a slug) in the data.

I did have to perform a last minute structure change on a recent website, and used a Sanity migration to do so. We could provide this migration as an example of how to change these

[Jamiewarb]

The main area this strategy may break down is where we might have URLs generated by multiple pieces of data, that it's harder to be deterministic. I.E. a URL that has a particular category slug and an article slug in the URL: domain.com/articles/my-category/my-article

I think it's an uncommon request, and one that can likely be handled by the user, rather than out of the box, but it might be good in v2 to think about how we can handle multiple types of routing like this, for non-canonical pages.