U4-10345 - Add possibilty to ignore collisions from an IContentFinder (U4-10345)

Created by Lennard Fonteijn 22 Aug 2017, 17:08:30 Updated by Sebastiaan Janssen 16 Jul 2018, 11:34:21

Tags: 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.

Comments

Lennard Fonteijn 22 Aug 2017, 17:09:00

Since it's already tagged as fixed.


Lennard Fonteijn 22 Aug 2017, 18:34:27

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.


Michal Koblasa 23 Aug 2017, 05:49:40

@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.


Lennard Fonteijn 23 Aug 2017, 21:30:00

Added a PR: https://github.com/umbraco/Umbraco-CMS/pull/2148


Lennard Fonteijn 06 Sep 2017, 22:25:08

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!


Ivo Kolář 13 Nov 2017, 11:39:36

Is aby update in this issue? This function is important for our projects.


Priority: Normal

Type: Feature (request)

State: Fixed

Assignee:

Difficulty: Very Easy

Category:

Backwards Compatible: True

Fix Submitted: Pull request

Affected versions: 7.5.6

Due in version: 7.12.0

Sprint:

Story Points:

Cycle: