Docs-website: Handle redirects from the old Docs site to the new Doc Site

[jpvajda]

With the change in site IA, some URLs will no longer route to the correct location on the new site. Also, existing redirects in the old site are in place for URLs that have changed over time. Therefore we need to support the redirect of URLs to the correct locations when the new Doc Site launches.

Goal

There are currently ~7550 redirects in total. Ideally we map all URLS to the correct location with a goal of 100% mapping, or a fall-back goal of all those that have been accessed in the last 365 Days

TODOs

• [x] review URL data set and decide on approach
• [x] Break down work as needed.

Considerations

• consider mapping the old IA to new IA and how we programmatically can determine a redirect location

• perhaps we consider a catch approach were if there isn't a 1:1 for match we direct them to the correct category on the site. This may allow us to feel confident we've completed the mapping but ensure if a URL was missed it would go to a location that would make sense to a user.

• finally, all broken redirects would go to 404 pages, so part of our instrumentation approach could be to capture what URL triggered a 404 for redirect analysis.

[tariqahmed]

• See if it's possible to limit to only redirects that are under a year?

[tariqahmed]

• The actual redirects themselves are easy, it's just assessing what to redirect from/to that's the challenge
• Complexity is around the Drupal side
• Dump the data from MySQL for reference
• We do send custom events to Insights to see if there were any dead ends
• Evaluate: Using the Insights history for a year, and just redirect off of that... concern: bot traffic, and if that can be filtered.

[tariqahmed]

Unknowns: is the data available
Complexity significantly reduces if we don't worry about directory URLs

[jpvajda]

We'll want to grab as much data on redirects as possible so we can assess the approach to this, @austin-schaefer @roadlittledawn could you exports the data for redirects with information such as:

• URL: Redirect From
• URL: Redirect To
• Count of Redirects per URL
• Date Redirect was last used?

Essentially this data is useful so the team can look at redirect dataset in it's entirety and come up with an approach.

[roadlittledawn]

Note re: remaining work.
The work in PR #500 added all redirects for basic page Drupal nodes by their ID (stored in Drupal with this pattern: node/1234).

Remaining work includes:

• Migrating redirects for all other content types (troubleshooting, release notes, etc). Basic pages likely had the most.
• Migrating / determining how to redirect taxonomy pages (e.g., the index pages that list links to content in a particular directory/category, landing pages). There's 1,181 records for those in the dev DB.

The majority of Drupal node redirects were stored with an ID, though there were a handful of redirects from one URL path to another URL path that I couldn't verify if they belonged to a particular node or were active. May want to audit those as well. There's a 143 records that fit that pattern in the dev DB.

[zstix]

@roadlittledawn would you mind updating the sp value for this ticket to reflect what's left? I dunno what the level of effort is for the remaining stuff.

[jerelmiller]

Update on this ticket:

Most of the remaining work was completed in #556. Based on @roadlittledawn's list above, I think we just need to figure out how to handle the taxonomy page redirects. Maybe we write those to an additional file?

@roadlittledawn if you wouldn't mind giving a sample of what the taxonomy redirect looks like, that would be super helpful. Awesome that we are so close to closing this out!

[jerelmiller]

Updated to a 2-point story with the remaining work.

[roadlittledawn]

Yeah maybe an additional file would work. Here's an example of a taxonomy term redirect. This would be all redirects for this taxonomy / index page: /docs/insights/insights-api/get-data.

[zstix]

After speaking with @roadlittledawn about the technical approach and @austin-schaefer about the business need, it sounds like we _do_ need the taxonomy redirects and that they're going to be a little tricky to set up since we don't have those "taxonomy pages" (read: index pages) until build time. I bumped this up to sp:5 since it feels a little heavier than a sp:2.

[austin-schaefer]

@roadlittledawn @jerelmiller @zstix : I saw in a @roadlittledawn comment above that we didn't initially have redirects for content types besides basic pages. Do we have those in place now for troubleshooting docs and release notes?

[jerelmiller]

@austin-schaefer yes, we should have redirects for all content types now. The only thing that should be left is the taxonomy redirects.

[roadlittledawn]

yep, what @jerelmiller said. also worth noting that i think we still have to create redirects for what's new posts since we store the files in a different pattern than their current URL. that was captured in a separate ticket, but having trouble finding that one

[roadlittledawn]

here it is! looks like it was marked as done in #670 , but requesting the first what's new post at its current URL does not redirect to thenew page.

is there still work to be done there?

[jerelmiller]

@roadlittledawn you aren't seeing that redirect yet because it's not released 😀. I just merged the PR this morning. The Release PR open at the time of this comment contains the redirect fix for what's new posts.

[roadlittledawn]

oh gotcha! sweet! thanks, @jerelmiller