Adding action name to VirtualPathArguments.Action has no effect

[stefanolsen]

Observations: When resolving a URL to a content item, and adding a custom action name to VirtualPathArguments.Action, when resolving, the URL is the same as if it was not passed.

Expected: The resolved URL should end with the custom action name.

Builds:

• EPiServer.CMS.UI.Core: 12.0.0-inte-021292
• EPiServer.Commerce.Web: 14.0.0-inte-020696

[lunchin]

Added to internal tracker

[jbearfoot]

Verified during testing that If action is something else than default ('Index'), the action is added to url. Verified in integration test like: urlResolver.GetUrl(PageLink, "sv", new VirtualPathArguments { Action = "Custom" });

[stefanolsen]

@jbearfoot: Which build versions did you test this with?

[jbearfoot]

I tested with the code on our release branch but I cant see that anything in this are has changed recently, so the code is likely the same as in the package you reported on. Is there anything else in your environment (some config setting or similar) that differs from default?

[stefanolsen]

@jbearfoot: I have found that it works perfectly fine if I inject UrlResolver, while it fails (as mentioned above) if I inject IUrlResolver.

It looks the first type resolves to DefaultUrlResolver, while the other one resolves to PipelineUrlResolver.

[jbearfoot]

Ah, I see. Yes as I have mentioned earlier, we have separated routing in a "core" implementation that resides in EPiServer.CMS.Core package. That package contains the abstraction IUrlResolver which has method string GetUrl(ContentReference contentLink, string language, UrlResolverArguments urlResolverArguments); Then there is a web aware routing implementation (based on endpoint routing) in EPiServer.CMS.AspNetCore, in this web layer is also the abstraction UrlResolver defined, that has the method GetUrl(ContentReference contentLink, string language, VirtualPathArguments virtualPathArguments); Now these methods looks very similar and the UrlResolver is also implemented as a facade over IUrlResolver. One difference is that VirtualPathArguments contains an Action property while UrlResolverArguments does not. And that is one of the things that happens in the UrlResolver facade (because at that level the concept of an action is known). Now to avoid having todo mappings between VirtualPathArguments => UrlResolverArguments we let VirtualPathArguments extend UrlResolverArguments but that also means (as in your case) that you can pass in a VirtualPathArguments to IUrlResolver but that will treat it as a UrlResolverArguments instance and hence it does not know about the Action property.

[valdisiljuconoks]

aha, that makes sense. thx for insights. this is one of the slippery stone to step on ;)

[jbearfoot]

Hmm, perhaps should not have let VirtualPathArguments inherit UrlResolverArguments, it made sense from a performance perspective to avoid allocating new objects and copy values but then it opened up for this not so obvious side effect...