Investigate Prismic solutions for restructuring Pages urls

[LaurenFBaily]

For the 'Page' content type in Prismic, urls should use parent page in url structure, not content type. Eg.

Current: www.wellcomecollection.co.uk/pages/accessibility
Ideal: www.wellcomecollection.co.uk/visit-us/accessibility

More info and full list of url changes: #11072

Use scenarios

Internal user
A content editor wants to add a new informative page to the website about our born-digital archives. They create a new 'Page' in Prismic and select wc.org/collections as the parent page and publish the page (for example, the solution could be different!). They manually add it as a card to the Collections landing page. They check the live page and see that it displays on the unique url wc.org/collections/about-our-born-digital-archives. The breadcrumb displays correctly (Home | Collections) and in the main menu ‘Collections’ is highlighted.

External user
Elise is planning a visit to the museum with her friend Beth. She find a few pages on the website which have useful information ahead of the visit and copies and pastes the urls into a draft email. (eg. wc.org/visit-us/accessibility and wc.org/collections/library-membership). That evening Elise goes back to writing the email and can easily see what web pages she has saved from a glance at the urls. She finishes writing the email and sends it to Beth with the helpful links included at the bottom. When Beth reads the email she sees the links and can tell before opening them what information they are going to include.

[LaurenFBaily]

I don't know if this is helpful but dropping here just in case - Prismic documentation on paths including nested paths using the route resolver. Also found a few forum chats which might contain clues eg. https://community.prismic.io/t/slugs-multi-level-urls/2165?page=2 and https://community.prismic.io/t/incorrect-uid-slug-with-fetchlinks-in-link-resolver/702

[rcantin-w]

@LaurenFBaily I think we said we'd need more context in the Description of this issue; let me know if you want to chat!

[LaurenFBaily]

I've updated the description above. Are there specific questions still outstanding on the outcome still? Can they be documented here if so?

I've included a possible solution in the internal use case above (selecting parent page) just as I was trying to find new ways to describe the outcome we want. The way in which we achieve that goal could be different, eg. we have a' different "Page" type per section rather than our universal Page. Ultimately this is about finding a way of reflecting the IA/hierarchy in the url structures.

[rcantin-w]

Looks good to me so far, great description thank you!

[LaurenFBaily]

I think what isn't documented is how many levels "deep" we will need it to work. We don't really have examples of this as the site is fairly simple/shallow (that's a compliment) but we should try and ensure we don't design a solution which means this is impossible in the future. For example What's in the collection could itself have child pages in the future. So we don't necessarily need it now, more about future-proofing.

[rcantin-w]

@LaurenFBaily do we think we'll put our foot down at some level-deep? As in, will we want to allow up to, let's say, 5 levels deep, or would we find a different solution at that point?

[LaurenFBaily]

Yes let's not get to five 😅. I think one additional level is reasonable eg. wc.org/primary-level/secondary-level/page-title

[rcantin-w]

Slack convo here

[rcantin-w]

URLs that currently exist that we need to add to the spreadsheet so we can officialise what they should be

• /stories/[contentType] (I think only /stories/comic is supported for this)
• /guides/
• /projects/
• /seasons/
• /concepts/
• multiple /works/ paths, but I assume we're not really touching that?

[rcantin-w]

More questions to answer (see comment just above), but the logic we'd suggest is ready for review - should not get merged in though.

[rcantin-w]

Presented solution to @davidpmccormick and talked through it, he tested it and it works well.

We just don't want to merge the PR before redirections, so we could stick with this PR and move #11072 to Blocked until #11069 is through... Although this will mean new redirections as well so maybe they should be released together?

[rcantin-w]

I will close this ticket and link the PR to #11072. I'm amending the work planning so it references these structure changes as well: https://www.notion.so/wellcometrust/Url-work-planning-86445fd42f724eb69a55961db7a4dd57