I'm testing uMarketingSuite on a "legacy" site where we've "hidden" the second level of the tree in URLs as well. After upgrading to v8 I've used DotSee.VirtualNodes to replicate the functionality. Whenever using a URL not matching the Umbraco "route" it seems uMarketingSuite fails to associate the right content. The hit is visible in the global traffic analysis but not on respective pages.
I'll go out on a limb and assume URLs are only matched with the default content finder or even using "proprietary code"? Would be nice to track using a page ID or even extend tracking in order to work around this.
Happy to provide further details if necessary.
I can confirm that this bug exists, and also if I add a new UrlContentFinder myself it does not work as it should work.
Can I borrow your brilliant mind for a moment to think along with us.
My code for the UrlContentFinder is this (in a default Umbraco starter kit solution on 8.6.x with uMarketingSuite 1.3 installed):
using ClientDependency.Core.Logging;
using System;
using System.Collections.Generic;
using System.Linq;
using System.Web;
using Umbraco.Core.Composing;
using Umbraco.Core.Configuration;
using Umbraco.Core.Configuration.UmbracoSettings;
using Umbraco.Core.Models.PublishedContent;
using Umbraco.Web;
using Umbraco.Web.Routing;
namespace umsMetVirtualNodes.Code
{
public class StartUpProvider : IUserComposer
{
public void Compose(Composition composition)
{
composition.UrlProviders().InsertBefore
public class JeffreysUrlProvider : DefaultUrlProvider
{
public JeffreysUrlProvider(IRequestHandlerSection requestSettings, Umbraco.Core.Logging.ILogger logger, IGlobalSettings globalSettings, ISiteDomainHelper siteDomainHelper) : base(requestSettings, logger, globalSettings, siteDomainHelper)
{
}
public override IEnumerable<UrlInfo> GetOtherUrls(UmbracoContext umbracoContext, int id, Uri current)
{
return base.GetOtherUrls(umbracoContext, id, current);
}
public override UrlInfo GetUrl(UmbracoContext umbracoContext, IPublishedContent content, UrlMode mode, string culture, Uri current)
{
//Just in case
if (content == null)
{
//otherwise return the base GetUrl result:
return base.GetUrl(umbracoContext, content, mode, culture, current);
}
//If this is a virtual node itself, no need to handle it - should return normal URL
if (content.ContentType.Alias == "product")
{
UrlInfo defaultUrlInfo = base.GetUrl(umbracoContext, content, mode, culture, current);
var originalUrl = defaultUrlInfo.Text.Substring(0,defaultUrlInfo.Text.Length -1);
var customUrl = originalUrl + "-" + content.Id.ToString() + "/";
return new UrlInfo(customUrl, true, defaultUrlInfo.Culture);
}
return null;
}
}
Question 1) I've implemented a UrlProvider and I expected this to generate url, but not map this back to the content. I thought I would have to implement a ContentFinder as well. But somehow this url magically gives me back to the correct content. Do you have any idea how that dark magic works?
In the DotSee.VirtualNodes package there is a content finder registered, so that is another case.
The way our code works is that does something like this:
var req = _publishedRouter.CreateRequest(reference.UmbracoContext, uri);
if (_publishedRouter.TryRouteRequest(req))
{
var content = req.PublishedContent;
var culture = req.Culture;
Given the incoming url we ask Umbraco (via the IPublishedRouter instance) to give us a possible node... If it gives us a node, we know it's internal and register it correctly in our table (so we can show in the Analytics-view)... But somehow this call in the case of DotSee.VirtualNodes does not map back correctly.
Question 2) Any idea why this wouldn't work or any advice on a better alternative?
We will look into this later this week as well, but maybe you spot something already.
1) I would expect that as well, and drilling into PublishedRouter I can see it looks for the first positive result from the content finder collection. I also checked out the DotSee VirtualNodes source, and it does provide a ContentFinder. The PublishedRouter does extensive debug logging when resolving, so maybe there's a hint there?
2) No idea. If I had access to absolutely all the code I would debug it. 😉
Here's the two files I'd start with:
Logging views when using "virtual nodes"
Hi,
I'm testing uMarketingSuite on a "legacy" site where we've "hidden" the second level of the tree in URLs as well. After upgrading to v8 I've used DotSee.VirtualNodes to replicate the functionality. Whenever using a URL not matching the Umbraco "route" it seems uMarketingSuite fails to associate the right content. The hit is visible in the global traffic analysis but not on respective pages.
I'll go out on a limb and assume URLs are only matched with the default content finder or even using "proprietary code"? Would be nice to track using a page ID or even extend tracking in order to work around this.
Happy to provide further details if necessary.
Lars-Erik
Hi Lars-Erik,
thanks for your bugreport. Appreciated :)
I can confirm that this bug exists, and also if I add a new UrlContentFinder myself it does not work as it should work.
Can I borrow your brilliant mind for a moment to think along with us.
My code for the UrlContentFinder is this (in a default Umbraco starter kit solution on 8.6.x with uMarketingSuite 1.3 installed):
using ClientDependency.Core.Logging; using System; using System.Collections.Generic; using System.Linq; using System.Web; using Umbraco.Core.Composing; using Umbraco.Core.Configuration; using Umbraco.Core.Configuration.UmbracoSettings; using Umbraco.Core.Models.PublishedContent; using Umbraco.Web; using Umbraco.Web.Routing;
namespace umsMetVirtualNodes.Code { public class StartUpProvider : IUserComposer { public void Compose(Composition composition) { composition.UrlProviders().InsertBefore
}
This will result in url's like https://localhost:44336/products/biker-jacket-1104/ where I only added in the ID of the node at the end of the url.
Question 1) I've implemented a UrlProvider and I expected this to generate url, but not map this back to the content. I thought I would have to implement a ContentFinder as well. But somehow this url magically gives me back to the correct content. Do you have any idea how that dark magic works?
In the DotSee.VirtualNodes package there is a content finder registered, so that is another case.
The way our code works is that does something like this:
Given the incoming url we ask Umbraco (via the IPublishedRouter instance) to give us a possible node... If it gives us a node, we know it's internal and register it correctly in our table (so we can show in the Analytics-view)... But somehow this call in the case of DotSee.VirtualNodes does not map back correctly.
Question 2) Any idea why this wouldn't work or any advice on a better alternative?
We will look into this later this week as well, but maybe you spot something already.
Thanks in advance,
Jeffrey
1) I would expect that as well, and drilling into
PublishedRouter
I can see it looks for the first positive result from the content finder collection. I also checked out the DotSee VirtualNodes source, and it does provide a ContentFinder. ThePublishedRouter
does extensive debug logging when resolving, so maybe there's a hint there?2) No idea. If I had access to absolutely all the code I would debug it. 😉 Here's the two files I'd start with:
https://github.com/sotirisf/Umbraco-VirtualNodes/blob/master/VirtualNodes/VirtualNodesContentFinder.cs
https://github.com/umbraco/Umbraco-CMS/blob/3bfd9b71e290354744d677440983ecd06c5c0788/src/Umbraco.Web/Routing/PublishedRouter.cs#L411
Author of VirtualNodes here. Don't know whether I could contribute anything to this particular issue, but please do let me know if so.
Hi Sotiris Filippidis,
thanks for the reach out. We're currently try to fix this (and I think our dev-magicians will work that out) and will keep the forum updated.
In case of any dark magic that we cannot solve or understand we will definitely reach out. Thanks for the offer :)!
Have a great evening,
Jeffrey
Hi Lars-Erik,
last week we've released version 1.4 which should fix this issue. Please let me know whethet it works!
Kindest regards,
Jeffrey
Seems good now! 👍
is working on a reply...