Look-up redirect in content finder for multi-lingual sites using path and legacy route prefixed with the integer ID of the node with domains defined

[AndyButland]

Prerequisites

• I have added steps to test this contribution in the description below

Resolves: #18714

Description

The linked issue raises an issue with redirects on websites where domains are defined in the content tree. I've traced it to a difference in what we store in the umbracoRedirectUrl.url column when a redirect rule is added.

For a URL of /en/test:

• With 13 we store e.g. 1057/test - where the number is the integer ID of the node where the domain is defined.
• With 15 we store /en/test

The difference seems to be in part about because the RedirectTracker component in 15 uses IPublishedUrlProvider.GetUrl(), whereas in 13 we used IPublishedCache.GetRouteById().

But there may be a bit more to it than that - even with 13, it seemed we could have a mix of URLs depending on configuration (see #18763).

Given we in theory could have a mix of redirect URLs in an upgraded site, I've fixed in this PR by amending the content finder, so we look up both formats.

To Test:

• Create an Umbraco set up with two languages
• Create a document type that varies by culture, is allowed at root and allows itself as a child.
• Create a root page using the document type in one of the languages.
• Add an /en domain to this page.
• Create a sub page under this using the same language.
• Rename the sub page.
• Rename it again.

Look in umbracoRedirectUrl.url and you'll see two redirects, e.g. /en/test and en/test-2.

Update once of the redirects to the 13 format, using a query like:

update umbracoRedirectUrl
set url = '1057/test', urlHash = '3fbca6debddf63167af3d7357c1f654b5beebe42'
where url = 'en/test'

The number prefix should be the integer ID of the root page you created above. It shouldn't have a leading / and the path should be the segment of the sub page only.
The URL hash you can generate from e.g. https://emn178.github.io/online-tools/sha1.html

Then via Content > Redirect URL Management check you can navigate to both old URLs and end up on the current version of the page.

[nikolajlauridsen]

The code looks fine, but I had some issues when testing. It might be because I misunderstood the premise a bit here.

I tried to do this with the not default language, so instead of doing it for English, I did it for Danish, the second language I added, and it doesn't work in that scenario because it can't find the domain.

So the question is, is this only supposed to work for the default language or for any language? Might be working as intended but I'm not sure 😄

[AndyButland]

Not quite sure if we are seeing the same thing, but I've pushed an update that fixes something I found.

To review what you reported I replayed the above testing steps, with one addition - also adding a /da domain to the root page. Then I tried renaming pages in both languages.

I do get the correct redirects then stored in the database and they work in the sense of taking you to the expected destination page when you navigate to the old URL.

In the backoffice though I couldn't see the original URL of the Danish page - it was rendered just as "#".

The reason looks to be that the URL we retrieve from the database is passed into the IUrlProvider, specifically NewDefaultUrlProvider, where it doesn't handle the path. It only handles the default domain - and I don't understand why that is. So with the latest update I've amended this to do so for all cultures.

That seems OK - but I am a little concerned I'm missing something here, as to why this behaviour was as it was before.

[nikolajlauridsen]

Yeah sorry I wasn't being clear, a bit of Friday brain going on 😛

I think the difference is in that I only have the default culture published, this tracks with the Can_Resolve_Urls_For_Non_Default_Domain_Culture_Only failing 😓

So my setup is like this:

I have English and Danish languages, English is the default, and my content structure is like this:

• Root (ID 1056) -> Published only in Danish has Danish domain /da no English domain
  • Child -> Published only in Danish

I've renamed the child twice, changing one of them like you mentioned:

It looks right in URL tracking:

But I get a 404 when I navigate to /1056/barn/

Looking a little into the code it seems to happen because the domain is null on the frequest in ContentFinderByRedirectUrl

I did a little bit of digging without going too much in depth, but it seems to happen because the culture in DomainUtilities.SelectDomain is null:

Which is why I wasn't sure it wasn't actually a bug, because arguably we can't really reasonably determine what the segment of the ID should be, when we don't know the culture, and there's no default, but I'm not 100% on this 😄

[AndyButland]

Just spotted one small thing wrong in your testing - /1056/barn/ isn't valid. It should be 1056/barn/ (i.e. no leading slash for the integer when this other format is used). That might be all it is - as there's some parsing going on to extract this numeric prefix.

[nikolajlauridsen]

You're right 🤦 sorry about that, that's my bad, it works fine after I did that 😄

Does seem like we still have a broken integration test though 🤔

[AndyButland]

Yes, I see that failure. It's because of the last update I've made in ea97d9a.

So perhaps that's not valid, but I'm a bit confused by it to be honest.

Seems we can have routes of /en/test and /da/test - but we only route the first as it's the default language, but not the second. I'm not following what the logic is of that. One to ponder next week perhaps.

Have reverted the previous update for now.

[AndyButland]

I've re-addressed this:

I do get the correct redirects then stored in the database and they work in the sense of taking you to the expected destination page when you navigate to the old URL.

In the backoffice though I couldn't see the original URL of the Danish page - it was rendered just as "#".

By just amending it in the presentation service - so if we can't get a URL from the route using the whole URL providers setup, if we have one that is a path, we'll display it anyway.

So I think this now improves the situation with redirects without making any amends to the actual URL provider logic. I.e. redirects for non-default languages now work, and they are displayed in the backoffice.

[AndyButland]

Just a comment to say we'll hold this for now. @kjac is digging into something that sounds related - with regard to routing non-default, variant content - so it makes sense to wait and see the outcome of that.

[AndyButland]

This is back on the table now. The work @kjac was looking at in the end was limited to the delivery API.

[nikolajlauridsen]

Bit unsure what state we ended in here Andy, but it looks good to me, so feel free to merge if you're happy 👍

[AndyButland]

I'll ask @kjac for a review too - hopefully he'll have time next week. I'm just a bit concerned this overlaps with something else he's been looking at regarding routing non-default languages, and if so, maybe I'm "band-aiding" around a deeper issue.