Slugs & Multi level URLs

Technologies Gatsby
#1

We have a client that wants multi-level URLs (3 deep) on their website. To achieve this we created a SLUG field and updated the LinkResolver so that slugs work effectively.
However, when it comes to RichText fields there is a problem. The link data in those fields only ever returns...

"data": {
  "id": "X3oe9xEAACIAZceQ",
  "type": "page",
  "tags": [], 
  "slug": "my-page",
  "lang": "en-gb",
  "uid": "my-page",
  "link_type": "Document",
  "isBroken": false
}

(Note, slug here seems to be the depreciated slug that Prismic used to use) So my question is, has anyone resolved this issue in React?

Or how does Prismic suggest we handle multi-level URLS effectively?

#9

Hi Team,

I'll try and help with this.

If this is a case that you are receiving the correct data in the linkresolver, but not in the rich text fields then maybe the link resolver isn't being passed correctly in your htmlserializer. Can you check how your links are handled there?

Alternatively if your URL's go no deeper than:

/grandparent/parent/uid

You can create a Slice Machine/ Nuxt project and create nested routes that way.

Let me know what you think.

Thanks.

#11

Alas, I can't use slice machine on this project, as part of it already React Based.

The Link resolver works fine when using Link Resolver standalone on buttons components etc. Its when I come to use this on links inside RichText. I ONLY receive the _meta info back from prismic

we are using - https://github.com/prismicio/prismic-reactjs for rich text elements

#12

OK, I see.

Have you checked out the section about custom links?:

#13

This issue has been closed due to inactivity. Flag to reopen.

#14
#16

I have the same issue
The element.data is not returning fields of the document I need to build the url
The slug is only the last part of the url which also depends on other data from the document;

ho wan I fetch data from the document within the rich text component?

Thanks a lot

#17

Hey SĂ©bastien Vassaux,

What field do you expect to be able to use here?

#18

Hello phil,

Since we cannot put part of paths in the uid, we created a field called urlPrefix
We have a type blog-post with an urlPrefix that can take multiple values, and our urls are build with this syntax: locale/urlPrefix/uid

We need to be able to build the url with this custom urlPrefix field. The inability to do so:

  • creates SEO issues
  • forces us to add redirects
  • prevents us from leveraging static optimization (because dynamic of redirects)
  • forces us to do ugly things

An alternative would be to let us add slashes / in the uid field
But I guess other people might want to query other fields of linked documents for other reasons...

#19

Are you building your project with Gatsby & GraphQL? because if that's the case you won't be able to access the document data to get the urlPrefix in the rich text field. It's just a limitation of these technologies. All though it would work in the link field if you pass the correct data to the link resolver.

Alternatively if you were using a technology like Next.js or Nuxt you can use the Route Resolver and build your URLs to the grand parent level. i.e. /grandparent/parent/uid

Having slashes in the UID won't be something that the team will be implementing unfortunately, but it is being tracked as a feature request.

#20

we are using nextjs

we're already passing a custom linkResolver but the links to resolve are for documents that might be of any part of the site.

If so, how can I build the route if I cannot fetch this urlPrefix the route depends on? Or what is the logic of this grandparent/parent thing ? what if we link a document from a completely different section of the website? (not the current parent or grand parent)

basically, we need to access the document data beyond its meta and so far we don't see any solution
and this is because we are using the same type for multiple sections of our website, not doing so would force us to maintain identical types and complexify our app logic

#21

Hi Sebastien,

Sorry about the late reply.

So it seems like you're describing completely arbitrary URL paths and you should be able to get the document data within the linkresolver like so:

return `/${doc.data.urlPrefix}/${doc.uid}`

As long as you're using a keytext field for urlPrefix and not using GraphQL, because GraphQL is different.

As for the other tool route resolver you can build links back to parent and grandparents defined in the docs by content relationships.

#22

Hello phil ! thanks !

However, I'm using graphQL...
any solution with graphQL?

I have this so far where doc is actually only the meta of the document

const linkResolver = (doc: any) => {
  const meta = doc as Meta;

  switch (doc.link_type) {
    case 'Document':
      return getUrlFromMeta(meta);
  }

  return null;
};
#23

There should be a solution depending on how links are being passed to the link resolver.

Can you show me where you're declaring the link resolver in your rich text fields or other places? Better yet if you can give me the github of your project I can test a solution.

Thanks.

#24

This issue has been closed due to inactivity. Flag to reopen.

#25
#26

Reopened for @sebastien.vassaux

#28
#29
#31

Hi.

I'm having the same issue as is described here. The thread doesn't come to a resolution. Only that you looked at the REPO. Was it unresolved?

I have pages 2 segments deep - '/page/page/' and having difficulty using the linkResolver. I can get the correct path from a relationship field but it's the richtext field that doesn't return the documents relationship field. Only the data that is described in the thread.

To quote from above thread

"Are you building your project with Gatsby & GraphQL? because if that's the case you won't be able to access the document data to get the urlPrefix in the rich text field. It's just a limitation of these technologies. All though it would work in the link field if you pass the correct data to the link resolver."

I am using a relationship field. How would I send this to the link resolver?

When I log what goes through the linkresolver.js I can see the problem. Here are the output for two different links.

Output hidden to public

See 2 result has data.section.uid which provides the slug to build the correct link /page/page/ but the first result doesn't have these fields? Do you know why?

Also the difference between the two fields above is the top output is a relationship field in a group field... We also get this output from a slice field that carries a rich-text field within it.

I'm not sure if that impacts the output or not?