UrlResolver and Shortcuts

Eric Herlitz

Vote:

Since we updated to 11.20.1 the UrlResolver will always resolve shortcuts.

For example, see the result above the variable where the ancestor page that we are trying to lookup has the URL /pageurl

var ancestor = whateverIcontent; // url:/pageurl
if (ancestor is PageData pageData && pageData.LinkType == PageShortcutType.Shortcut)
{
    // url:/pageurl/page
    var asd1 = UrlResolver.Current.GetUrl(pageData);

    // url:/
    var asd2 = UrlResolver.Current.GetUrl(pageData.ParentLink);

    // url:/pageurl/page
    var asd3 = UrlResolver.Current.GetUrl(pageData.LinkURL); 

    // url:/pageurl/page
    var asd4 = UrlResolver.Current.GetVirtualPath(pageData);

    // url:/
    var asd5 = UrlResolver.Current.GetVirtualPath(pageData.ParentLink);

    // url:/pageurl/page
    var asd6 = UrlResolver.Current.GetVirtualPath(pageData.ContentLink);
}

If I'd like to resolve the url to the page at /pageurl that would be impossible using the UrlResolver. We made the update from 11.13.2 to 11.20.1, did I miss the release notes on that API change?

#230594

Edited, Nov 09, 2020 15:51

Quan Mai

Vote:

I believe such thing is not intended, most likely an unwanted side effect of the url-caching thing. I will ask CMS Core team to look into this and get back to you.

#230595

Nov 09, 2020 16:13

Eric Herlitz - Nov 09, 2020 16:22

Thanks Quan

Tomas Hensrud Gulla

Vote:

The release note: https://world.episerver.com/documentation/Release-Notes/ReleaseNote/?releaseNoteId=CMS-14788

Part of release 339: https://world.episerver.com/releases/episerver---update-339/

#230603

Nov 09, 2020 19:11

Eric Herlitz - Nov 09, 2020 19:51

There you go, thanks. I would still argue that this isn't a wise change.

Johan Petersson

Vote:

I'm interested to know why you want to resolve the URL to a page that has a shortcut?

#230626

Nov 09, 2020 23:59

Eric Herlitz - Nov 10, 2020 12:29

The problem is if you want to resolve IContent from an URL (e.g /pageurl) in order to fetch all let's say childnodes from that very instance. The current UrlResolver will instead return the IContent object from the linked page (e.g /pageurl/page) by design. We may also sometimes need to fetch ancestors or access properties based on an URL.

My main concern is that we can no longer use or trust the structure to build certain types of navigation or when resolving various types of content based on its placement.

Also, since the structure is typically managed by content editors who may select to "redirect" pages using shortcuts we may end up with "us" expecting to fetch certain content using built-in APIs but never really knowing if it will be correct. I'd prefer to be able to get what I'm asking for when resolving data.

(Further discussion have moved to yammer)