Skip to content
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

V15: Handle domains in invariant content #17937

Open
wants to merge 1 commit into
base: v15/dev
Choose a base branch
from

Conversation

nikolajlauridsen
Copy link
Contributor

Fixes an issue where domains was broken for invariant content, given the following setup

  • EN Root - Has domain /en with English culture
    • Child
  • DA Root - Has domain /da with Danish culture
    • Child

You would expect that the URLs return by Url() to be /da/ for the danish root, and /da/text-da/ for the danish child, however this was not the case, and it would instead return the "default" URL

The reason for this is that GetLegacyRouteFormat would always look for a domain with the passed in culture, however this doesn't make sense in an invariant setup like this, since the culture will always be null, and we'll never find any domains.

We can see that similar logic was applied in DomainCacheExtensions.GetAssignedWithCulture in the old routing system

Testing

Create a setup like above and check that URLs are generated correctly.

This template is a helpful way of doing so:

@inherits Umbraco.Cms.Web.Common.Views.UmbracoViewPage
@{
    Layout = null;
    var descendants = Model.DescendantsOrSelf();
}
<html lang="en">
<body>
<h1>@Model.Name</h1>
<ul>
    @foreach (var desc in descendants)
    {
        <li>@desc.Name - @desc.Url()</li>
    }
</ul>
</body>
</html>

@nikolajlauridsen nikolajlauridsen marked this pull request as ready for review January 10, 2025 12:46
Copy link
Contributor

@AndyButland AndyButland left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've tested this out and can confirm the fix works as expected.

Got a few questions from trying to following the logic of where this is used - around NewDefaultUrlProvider v DefaultUrlProvider - but I'll save those for a team catch-up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants