U4-9430 - URL collision error on published accessible pages with virtual directories

Created by Brian Powell 23 Jan 2017, 19:40:02 Updated by Sebastiaan Janssen 14 Aug 2018, 07:36:45

Relates to: U4-9442

Relates to: U4-9551

Relates to: U4-10345

Relates to: U4-9337

Subtask of: U4-9609

Umbraco 7.5.7 has introduced an error with URLs for Umbraco instances hosted in virtual directories. I think this is an unintended side effect of U4-9337.

I maintain two Umbraco instances for a non-profit that are hosted in virtual directories on their GoDaddy hosting. The virtual directories are folders underneath the main site. Umbraco is installed in the \myvirtualsite.org folder. I can go to a page on the virtual site at http://myvirtualsite.org/mypage or http://parentsite.com/myvirtualsite.org/mypage. In v7.5.6 and earlier, when getting its Url property or viewing the 'Link to document" on the Properties tab in the Umbraco backend, I would get /myvirtualsite.org/mypage.

In Umbraco 7.5.7, I can access this published page on the public site the same as before. The Url property of the published page is the same as before. I can publish/unpublish existing and new pages the same as before, and any changes I make are reflected, but now when I view the "Link to document" tab on the Properties page, I get an error "This document is published but its URL would collide with content (error)".

Everything seems to work the same as before except for the URL display in the backend. I've unpublished/republished the site root page, recycled my app pool, but nothing seems to fix this.

1 Attachments

Download umbraco.dll


Sebastiaan Janssen 24 Jan 2017, 11:01:04

Do you have a host name set in Umbraco on the parent/ancestor of this node?

Brian Powell 24 Jan 2017, 13:58:23

I don't have any hostnames set in Umbraco. The problem happens for all nodes in these Umbraco installs including the top-most node.

To clarify, the "root" site is not in Umbraco. The two sites that use Umbraco are separate Umbraco installs in their own virtual directories (and physical directories) below the root site.

Sebastiaan Janssen 24 Jan 2017, 14:19:53

I think it might have accidentally worked up until now, you should definitely try setting the hostname(s) that you want to use for this site to alleviate the problem. I am hoping that will help, meanwhile we can look at the actual cause of the problem.

Brian Powell 24 Jan 2017, 14:35:09

I set a hostname but it didn't make a difference. I still get same collision message in the backend. The URLs still resolve as before on the public frontend.

Sebastiaan Janssen 24 Jan 2017, 14:38:03

Any quick ideas for a workaround @zpqrtbnk ?

Tom Fulton 30 Mar 2017, 23:10:00

Hi @bitmapped, did you ever get anywhere on this one?

I have the same issue on a single Umbraco site that runs in a virtual directory, after upgrading from 7.5.6 -> 7.5.11. Everything seems to be working except the Link to Document field, which shows the same error as you.

I do not see the issue when running the same site at the root instead of a virtual directory.

Going to dig into this more, just thought I'd check in first!

Brian Powell 31 Mar 2017, 14:06:31

@tomnf No, I never got anywhere.

Tom Fulton 01 Apr 2017, 21:11:17

Hi, I looked into this and was able to fix it for my case. I haven't fully tested this with multiple domains and other scenarios, but it's simple enough that I think it should work everywhere.

In 7.5.7, some code was added to test for collisions ([link|https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web/Routing/UrlProviderExtensions.cs#L70-L74]). To do so, it creates a "fake" {{PublishedContentRequest}} and tries to route it. However, when creating the PCR, we're providing an incorrect URL format: {{http://mysite.local/myvdir/}} as opposed to {{http://mysite.local/}}, which is the format {{UmbracoModule}} uses when creating it's PCR on the front-end.

To fix this I updated the collision check to wrap the URI in: {{UriUtility.UriToUmbraco(uri)}}, to match what {{UmbracoModule}} uses when creating it's PCR ([1|https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web/UmbracoModule.cs#L132-L134], [2|https://github.com/umbraco/Umbraco-CMS/blob/dev-v7/src/Umbraco.Web/UmbracoContext.cs#L267])

...and now the Link to Document field works as expected for me.

The code is [here|https://github.com/tomfulton/Umbraco-CMS/commit/ba670586eba14092e6f1d20ee5e9aceb93e05f23] - I can send a pull request if anyone can confirm this makes sense. I don't fully understand the scope of the collision issues just yet.

@bitmapped - I also attached a DLL here (built against 7.5.11) if you want to give it a shot for your case.


Brian Powell 04 Apr 2017, 14:51:22

@tomnf The DLL fixed things for me. I'd suggest submitting a pull request with your code so it can be included in the main codebase.

David Twamley 11 Apr 2017, 02:03:10

Same error here after jumping from 7.4 to 7.5.11. I was using an UmbracoVirtualNodeRouteHandler and IUrlProvider. My workaround was to create matching code in LastChanceContentFinder that returned the proper node id so the url testing code was satisfied. AFAIK that new code is unnecessary for the front-end site but allows the "Link to Document" in the back office to populate properly instead of showing the "This content is published but its url would collide with content (error)" message.

Brian Powell 16 May 2017, 17:47:50

@tomnf Wanting to ping you again about submitting a pull request with your fix. It'd be nice to get this incorporated into the base so we can all upgrade and use the standard codebase going forward.

Brian Powell 09 Jun 2017, 15:43:57

I just submitted a pull request based on @tomnf's code so we can get this problem fixed in the codebase. https://github.com/umbraco/Umbraco-CMS/pull/1992

Stephan 19 Jul 2017, 10:16:59

testing for collisions means we get the url of the content item (via url providers), and then we try to route this url back into Umbraco and see whether it leads to the original content item (no collision) or to some other content item (collision) or to nothing (error).

I guess in the OP case, the url ends up being "/vdir/path/to/content" which we try to route as-is, and it goes nowhere, hence the error, because what we should try to route is "/path/to/content" ie with "/vdir" removed

So yes, UrlProviderExtensions.GetContentUrls should strip the vdir and sanitize the url before trying to route it.

@bitmapped using UriUtility.UriToUmbraco is indeed the way to go, however you're not doing it in the right place. The Uri produced by

var uri = new Uri(url.TrimEnd('/'), UriKind.RelativeOrAbsolute);

can end up being relative, and this would kill UriToUmbraco - so you want to add

uri = UriUtility.UriToUmbraco(uri);

''after'' it's been made absolute - ie right after

if (uri.IsAbsoluteUri == false) uri = uri.MakeAbsolute(UmbracoContext.Current.CleanedUmbracoUrl);

making sense? if you can update the PR I'll be happy to merge!

Stephan 20 Jul 2017, 08:21:46

right, that was a lazy answer - have merged ''and'' applied the fix, all good ! thanks!

Brian Powell 20 Jul 2017, 20:13:39

@zpqrtbnk Thanks for taking care of this and for putting in the fix!

Rob Carlaw 21 Jul 2017, 10:08:30

Any idea when/ if this will be merged and released with core?

Stephan 21 Jul 2017, 11:09:28

Has been merged in dev-v7 branch already so will be released with next version of 7.6 ie 7.6.5.

David Peck 26 Jul 2017, 12:43:39

Hopefully this will fix my issue too. I've got the same behaviour, but my only VD is for the media directory.

Dan White 08 Aug 2017, 18:31:38

@zpqrtbnk I've upgraded to 7.6.5 but I'm still getting the error when implementing an IUrlProvider for the home node as seen in this post https://24days.in/umbraco-cms/2014/urlprovider-and-contentfinder/

Brian Powell 08 Aug 2017, 18:34:14

FWIW, 7.6.5 is working fine for me in a virtual directory. I'm not using any custom UrlProviders.

Lennard Fonteijn 22 Aug 2017, 10:28:33

I have the same issue with newer Umbraco's. We have a IContentFinder and IUrlProvider. We have newsletters separated from the root-website so the nodes are purely data-containers with no visual representation. Inside the root we have a node called Newsletters / Detail, to which the Newsletter object outside the root has to be redirected to (using an IContentFinder). @zpqrtbnk's test if the requested URL leads back to same object is in this case undesirable, since it's intended behavior! The only reason we have a IUrlProvider is so you can still use content-pickers and end up at the correctly rewritten url.

Lennard Fonteijn 22 Aug 2017, 16:49:52


I would probably add a new property on the PublishedContentRequest allowing you to skip this particular behavior after TryGetContent has run. I'll make a PR for this.

Michal Koblasa 23 Aug 2017, 05:36:06

@LennardF1989 We use it exactly in same way, but for catalog landing page behavior. Still encountering problem with marking duplicit contant. So for us this ticket is not fixed.

Priority: Normal

Type: Bug

State: Fixed


Difficulty: Normal


Backwards Compatible: True

Fix Submitted: Inline code

Affected versions: 7.5.7, 7.5.11, 7.6.3

Due in version: 7.6.5

Sprint: Sprint 63

Story Points:

Cycle: 3