I have an issue in a multisite installation whereby we have a custom IContentFinder to resolve date folder based content in areas such as news, blogs, press releases etc. This works fine in the front end, however, the back office incorrectly reports url collisions because it is unaware of the domain associated with the current node being edited.

Take the following content structure:

• Site 01

  • Homepage (Hostname: example1.com)
    • News
      • News Article 01 (Url: example1.com/news/2019/03/news-article-01/

• Site 02

  • Homepage (Hostname: example2.com)
    • News
      • News Article 01 (Url: example2.com/news/2019/03/another-article-01/

• Site 03

  • Homepage (Hostname: example3.com)
    • News
      • News Article 01 (Url: example3.com/news/2019/03/yet-another-article-01/

All 3 news articles resolve correctly under their relevant domains on the front end but the articles in site 2 & site 3 all have the error…

This document is published but its url would collide with content (error)

This error message is actually incorrect and it's just a result of it not finding a match.

All site editors edit content via example1.com/umbraco/ and I have pinned this issue down to the IContentFinder which looks as follows:

public override bool TryFindContent(PublishedContentRequest request)
{
    var absUrl = request.Uri.GetAbsolutePathDecoded();

    // Define a regular expression we can use to match the date folder structure
    var pattern = @"^\/(.*)((?:19|20)\d\d)\/(0[1-9]|1[012])\/(.*)?$";
    var matches = Regex.Matches(absUrl, pattern);

    // Check if we have a valid request and something that resembles the date format in the path if not leave here
    if (request == null || !Regex.IsMatch(absUrl, pattern) || NodeHelper.Instance.CurrentSite == null)
        return false;

    var match = matches[0];

    // The first group is the path to the parent node
    var rootPath = match.Groups[1].Value;

    // The 4th group is the url name which comes after the datefolder parts
    var urlName = match.Groups[4].Value;

    // Build the full path/route to the node
    var route = request.HasDomain ? string.Concat(request.UmbracoDomain.RootContentId.ToString().EnsureEndsWith("/"), rootPath, urlName) : string.Concat(rootPath, urlName);

    LogHelper.Debug<DateFolderContentFinder>($"Attempting to find node at route {route}");

    // Attempt to locate a node using the route
    var node = FindContent(request, route);

    // If no match is found we can leave at this point!
    if (node == null)
    {
        LogHelper.Debug<DateFolderContentFinder>($"No node found using route {route}");
        return false;
    }

    LogHelper.Debug<DateFolderContentFinder>($"Node {node.Id} found using route {route}");

    // Assign the node to the PublishedContent property for the request
    request.PublishedContent = node;

    // Return a true value to indicate a match was found
    return true;
}

Having stepped through the method in the back office it's obvious that the issue is the fact that request.UmbracoDomain.RootContentId is the node with the domain matching the url we are editing from e.g. example.com in this case. I can't find any way to grab the rootNodeId for the homepage relating to the current node being edited so hoping that it's just a case of me having stared at this for so long I can no longer see the wood for the trees!

I'm sure that I can check request.RoutingContext.UmbracoContext.IsFrontEndUmbracoRequest and do some magic to cater for the back office in a different way and get around this issue. It's not enough to just attempt to match a route based on the absolute path for the url as there could be two sites with content at matching paths.

Any input appreciated.