For example, the path /aaa/bbb/ccc where "bbb" comes from a doctype that is defined to be hidden, becomes /aaa/ccc.
I tested it with Umbraco 7.5.2 and the new 301 redirect functionality and I discovered that if I use the example above and then change the "ccc" node name to "ccc2", then a new redirect rule is created but it redirects as follows:
/aaa/bbb/ccc to /aaa/ccc2
instead of
/aaa/ccc to /aaa/ccc2
resulting in a 404 when trying to access /aaa/ccc (the old url with the hidden segment)
I had a look at the event handler's code, but I can't be sure if there is something that could be fixed there or something I could do on my package:
I would like some help here - I preferred to discuss it here than in the tracker, since I'm not sure who can do what to fix this or even whether it's a bug or not.
I believe somebody from the core team mentioned that there will not be support (initially, at least) for more advanced scenarios like this. IIRC, they used international URL's as one specific example that wouldn't work with the redirect tracking (e.g., /en-us/about wouldn't redirect to /en-us/about-us as one might expect).
I bet you could recreated what that feature is doing, but I wonder if the better solution would be to find a way to generically implement a fix in the Umbraco core. Perhaps Umbraco could do a better job of figuring out the old and new URL's for redirects (e.g., by relying more on URL providers, or by providing some other extensible means of providing a URL to the code that manages redirects).
So I guess I should just add a warning to the package's description for now and leave it as is - wouldn't want to stir things more since I believe it's going to be improved anyway if people start using it.
301 redirect handler and omitting url segments from path
I have created a package called Virtual Nodes (https://our.umbraco.org/projects/website-utilities/virtualnodes/) which essentially omits url segments of specified document types from the url path.
For example, the path /aaa/bbb/ccc where "bbb" comes from a doctype that is defined to be hidden, becomes /aaa/ccc.
I tested it with Umbraco 7.5.2 and the new 301 redirect functionality and I discovered that if I use the example above and then change the "ccc" node name to "ccc2", then a new redirect rule is created but it redirects as follows:
/aaa/bbb/ccc to /aaa/ccc2
instead of
/aaa/ccc to /aaa/ccc2
resulting in a 404 when trying to access /aaa/ccc (the old url with the hidden segment)
I had a look at the event handler's code, but I can't be sure if there is something that could be fixed there or something I could do on my package:
https://github.com/umbraco/Umbraco-CMS/blob/release-7.5.2/src/Umbraco.Web/Routing/RedirectTrackingEventHandler.cs
I would like some help here - I preferred to discuss it here than in the tracker, since I'm not sure who can do what to fix this or even whether it's a bug or not.
I believe somebody from the core team mentioned that there will not be support (initially, at least) for more advanced scenarios like this. IIRC, they used international URL's as one specific example that wouldn't work with the redirect tracking (e.g.,
/en-us/aboutwouldn't redirect to/en-us/about-usas one might expect).Here's the main issue for this feature, and I think some of what I mentioned above was in the comments: http://issues.umbraco.org/issue/U4-8802
I bet you could recreated what that feature is doing, but I wonder if the better solution would be to find a way to generically implement a fix in the Umbraco core. Perhaps Umbraco could do a better job of figuring out the old and new URL's for redirects (e.g., by relying more on URL providers, or by providing some other extensible means of providing a URL to the code that manages redirects).
Thanks Nicholas,
I guess you are talking about this: http://issues.umbraco.org/issue/U4-8802#comment=67-30584
So I guess I should just add a warning to the package's description for now and leave it as is - wouldn't want to stir things more since I believe it's going to be improved anyway if people start using it.
is working on a reply...