-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Stop landing pages from rendering at the dynamic route #11354
Conversation
Size Change: -36 B (0%) Total Size: 982 kB
ℹ️ View Unchanged
|
Address this comment within this PR https://github.com/wellcomecollection/wellcomecollection.org/pull/11353/files#r1822641388 |
@@ -185,14 +185,11 @@ const EventPage: NextPage<EventProps> = ({ | |||
url: '/events', | |||
text: 'Events', | |||
}, | |||
...event.series.map(series => { | |||
console.log(series); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just removed this log (I could see some logs in Kibana, unsure which ones they are but thought I'd remove the ones we don't need).
@@ -84,9 +84,7 @@ const stageApiToggleCookie = createCookie({ | |||
value: 'true', | |||
}); | |||
|
|||
// TODO: context.addCookies should run for the first test of a suite (even on beforeAll/beforeEach) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This TODO is 3 yrs old, and we don't want all scenarios to have cookies added, so removing.
const isLandingPageRenderingAsSubPage = | ||
pageId === siteSection && | ||
context.resolvedUrl.indexOf(`/${siteSection}/${pageId}`) === 0; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A little bit verbose to my taste, will take ideas on cleverer ways of checking this.
|
||
return `${docSiteSection ? '/' + docSiteSection : ''}/${uid}`; | ||
// Prismic previews come through here. | ||
if ('tags' in doc) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
does this mean that if there is a sitesection tag, it would take precedence over doc.siteSection
– and if so is that ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I guess so yes, and if so it should still be the correct siteSection
, so I'd say it's ok!
What does this change?
#11341
Currently in prod, we render all pages tagged with the correct section at
/[section]/[uid]
, which means that the landing page (e.g. 'visit-us'), which is tagged with the 'visit-us' section, also renders there: https://wellcomecollection.org/visit-us/visit-usWe never link to that URL, but I'm thinking we also don't want to allow it, so this covers that.
We also simplify the
linkResolver
logic and ensure all scenarios consider whether or not the linked page is a landing page.How to test
Run locally and try all landing pages, like http://localhost:3000/visit-us/visit-us (or get-involved, or about-us)
Make sure it doesn't break anything that should work though.
http://localhost:3000/pages/visit-us
http://localhost:3000/pages/accessibility
http://localhost:3000/visit-us/visit-us
etc.
I'd also say to double check the Prismic preview still works since we've amended the
linkResolver
.How can we measure success?
Just less confusion and clearer rules for Page paths.
Have we considered potential risks?
N/A if we test right and tests pass.