We have moved to GitHub Issues
Created by Lennard Fonteijn 22 Aug 2017, 17:08:30 Updated by Sebastiaan Janssen 16 Jul 2018, 11:34:21Tags: PR Gold partner
Relates to: U4-9430
Since I can't re-open old issues once fixed: http://issues.umbraco.org/issue/U4-9430
At my company, we use a IContentFinder and IUrlProvider for a multiude of Umbraco sites, and we have been doing this for a long time. After updating a handful of these to the latest and greatest Umbraco, this no longer works as before. Routing still functions fine as before, but looking at the URL of a published page in the backoffice mentions there is a collision with another published node, which is rather annoying as customers use this a lot to quickly browse to the pages they need.
To explain the situation, we for example separate newsletter-nodes from the root-website to enforce a clear separation between view and data. Inside the root we have a node called Newsletters / Detail, which the Newsletter-node outside the root has to be rewritten to. For this we use IContentFinder. We have an IUrlProvider to generate a proper URL for this situation. This worked fine on all websites prior to 7.5 at least.
@zpqrtbnk's mentioned in the comments of the other issue he added a test to see if the requested URL leads back to same node. I tracked that commit down to this:
This check is in my case undesirable, as we fully intend it to end up at a completely different node!
An imagined workaround without modifying the core would be to wrap the PublishedContent you set on the PublishedContentRequest object in another object and overrule the Id, but that just seems really hacky.
I would probably add a new boolean on the PublishedContentRequest instead, allowing you to skip this particular behavior after TryGetContent has run, so an IContentFinder can set this when desired. I'll can make a PR for this.
Since it's already tagged as fixed.
It's awful, it's bad, but here's the workaround as I imagined it: https://gist.github.com/LennardF1989/aec5476f269b30e788d4169459300734
Pass the IPublishedContent you want to set on PublishedContentRequest to the constructor of the WrappedPublishedContent, then set the Id to the original source Id, and you should bypass the collision warning.
@LennardF1989 This one is real issue for us. Our currently running pages cannot be updated because we use landing pages for catalog thru IUrlProvider and IContentFinder, where multiple umbraco nodes ends up on same node used for catalog.
Added a PR: https://github.com/umbraco/Umbraco-CMS/pull/2148
I had to update this one to showstopper. The workaround I provided does not work on sites which extensively use the ModelBuilder on the templates, because the @inherits will fail with a WrappedPublishedContent when a different type is expected. I may or may not have had a case where the workaround breaks the whole Umbraco Cache so badly, it needs an iisreset... So use at your own risk!
There are most likely ways around this limitation by replacing the ModelBuilder ViewModels with more flexible versions (regardless not a bad idea to play with once, but alas), but either way would really love for someone to look at the PR and manually do the same thing or accept it, because it's killing our workflow and the workaround which seems to work, but probably introduces more than we bargain for!
Is aby update in this issue? This function is important for our projects.
Type: Feature (request)
Difficulty: Very Easy
Backwards Compatible: True
Fix Submitted: Pull request
Affected versions: 7.5.6
Due in version: 7.12.0