Closed Jamiewarb closed 3 weeks ago
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.
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
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.
The other place this might be important is with parent/child pages. Although that'll depend on if anything fancy happens with that. This guide may be a little overkill, but has some interesting approaches that I had tried out in testing.
I've integrated the Pathname field from @tinloof/sanity-kit
, but it has some issues that I'd like to look at addressing in the future:
required
validation error doesn't trigger (as it technically has a value). This needs a neat way to be handled, as it should be the same as required
in that no value is thereWill open a new issue for these points
Background
Documents that have an attached URL need a field to put this.
Potential Strategies
There's two schools of thought for Sanity slugs:
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: